Been looking around at many different posts of people who have found in site design within muse the case where there is a white gap to the right of the screen, with the addition of a horizontal scroll bar.
In most cases, Muse folks have responded to check that there is no object outside of the page area. I have done this, but the problem persists.
I have seen in other cases Muse staff who have checked peoples files and then said something like "You have a black box in the background, set to stretch to browser width - Delete this and replace with browser colour"
Now, I cannot do the above as I have a number of image elements within containers which are stretched to browser width.
I had posted another discussion (which I will close and point here) before I had gone through the site and removed all the client branding and content.
Please check the home (root page) below and particularly the view port width between 1400px and 1238px - Note the horizontal scroll bar and white gap. I have only noticed it on this breakpoint, but apparently it is happening elsewhere too.
Please see testing page here: http://clients.firedog.co.uk/test/
Muse file and assets: Dropbox - Test
Copy link to clipboard
Before going on:
You have tons of elements outside your page/breakpoint boundaries!
To demonstrate this, please follow these steps:
Now you see, that many elements run out of your page/breakpoint borders.
You simply mixed up your page with the representation of the browser background, perhaps, because you thought, the scrubber’s position (scrubber = grey vertical handle top right of the breakpoint bar) indicates your page width. But this isn’t the case. In adaptive layout, the widest „breaskpoint“ isn’t really a breakpoint, but it represents the browser window. By colouring your page temporarily, this error is quite clear to see.
So please correct this, and if there are more issues, give us a new .muse file. God luck!
Forgive me for being simple - But I followed above guidance and I am still not getting it. I have two-three primary elements which I agree are dragged out beyond the page "trim", but they are set to "Stretch to browser width" which I thought automatically triggered when you dragged the side of an element to the max visible area in Muse, being the breakpoint width, rather than the aforementioned page width.
Also, does page size include or exclude the gutter that one chooses? As sometimes I have elements which fall into the gutter space, and I wonder if this is "allowed"
So, in summary - Can you let me know how to set up an element within the page (For example the image container with the building render), that falls within the grid of the page width YET also stretches to browser width?
Thank you in advance,
Also Gunter, I forgot to add. I had already tested a bunch of scenarios, removing elements on the page. Deleting all three "stretch to browser width" containers helped a little, but I am still getting horizontal scrolls just near the edge of the breakpoint, even though there is absolutely nothing within the page bounds, and that is excluding the gutters too. Note the bottom right side of this screenshot.
Maybe I don't fully understand page width vs. what displays as grid vs. viewport area, and when the breakpoint does its switch to next smallest breakpoint, and therefore, where the boundaries for graphics are, in order to avoid elements falling outside to the maximum permissable page area.
For better visualisation, I coloured the breakpoint/page width orange, and the „misbehaving element „yellowish" (ochre)
1. There are 2 textboxes at breakpoint 960, which exceed the breakpoint boundaries at the right side. Make them smaller (or responsive width):
2. There is one rectangle at breakpoint 768 px exceeding the breakpoint boundaries. Make it responsive width:
Gunter. Wow, I'm going to try that out. No doubt I have a bunch of these causing white blocks on various breakpoints and pages.
whats a good methodology for bug fixing in this manor? I note that I should probably use fills on my text boxes if I do the colour background technique.
Ill reply back on how it goes!
The best way for bug fixing: Delete elements and look, what happens.
If the issue persists, delete the next bunch of elements.
If the issue is gone, restore the elements, you deleted in the last step and delete only some of them.
Time consuming, but this process may be easily avoided, if you check very often during the creation process and start with only one breakpoint (normally the widest).
Often, Muse beginners are layouting like they’d do , when creating a print layout: Place all elements, place text and so on, and when ready, preview in browser – and … uups!
Hi Gunter. Sorry - Whilst good advice for best practice, none of these amends changed my primary bug. I understand your feedback re: other breakpoints but I am unsure if they have any bearing on the breakpoint where I have the problem (1440px fixed)
If you scale the browser window from this breakpoint down you will note a horizontal scroll appears. If you use said scroll and move to right, you get a large white box which indicates page content where there is none.
I used the process of deleting items and it seems to be related to the master page, perhaps the footer - But I can't isolate the specific problem.
Not really true! The issues I found, of course affect your page by causing horizontally shift in the respective breakpoints. So, this IS a solution.
Maybe I didn’t see the specific problem you are describing now. That is one reasen, to reduce your file to the „misbehaving“ elements. You can’t expect, that we revise every single issue on every single breakpoint.
Again: Give us a corrected .muse file. But please, please, please: Only the index page, without any element, which don’t affect your issue. If you don’t reduce your site this way, we have to do it – and this will reduce our time for the issues of other users.
To clarify and to simplify - I have deleted all the other breakpoints. There is only the index page, and a master page with header and footer elements. Hoping this makes it simpler to find the culprit.
Copy link to clipboard
Do you see all these elements bleeding out of your breakpoint/page width?
I think, you are confusing different things:
The actual page/breakpoint width is not the place, where the scrubber is placed (scrubber = this grey vertical handle top right of the breakpoint bar.
If you are not sure where exactly your page/breakpoint area is, make sure, that no element is selected. Then use the „Fill“ command in the upper control strip to colour your page background temporarily. Now ypou will see, that many of your fixed width elements are placed completely wrong (Note: I am not talking about the browser wide elements, but the fixed width ones.
One more issue – perhaps the one you are thinking about primarily:
Look at these sample files: https://www.dropbox.com/s/6ebepdeo0lpdjs4/CF_Testing.zip?dl=0
The zip-file contains 2 .muse documents.
01.muse is the one, which doesn’t work correctly:
This seems to be related to the bug, I described here: https://forums.adobe.com/message/9942775#9942775
Again: ankushr40215001: what do you think about this? (Sorry for calling you that often!)
Interesting enough: If I build the site as I would do (respecting, that the widest „breakpoint“ is not really a breakpoint, but represents the browser background (See my above posts No. 10) all works as expected. And even Chrome does, want I want it to do.
The .muse file „02.muse“ demonstrates this.
Yeah, it's the same bug and I have logged it already.
If we have any object for say a rectangle behind a composition, it is shifting in chrome browsers.
Thanks for digging into the issue this much, it makes our bug logging job so easy, really appreciate your time and patience.
Hi Gunter, your screenshot shows a breakpoint not included in the discussion. It only displays messed up like that, because I deleted the other breakpoints. I believe I understand the rules of muse and placing elements in a grid. I believe this is probably a bug as this white space issue has been acknowledged in latest release, where there has been an attempt to correct it. But I am still concerned that it exists.
I believe this is probably a bug as this white space issue has been acknowledged in latest release, where there has been an attempt to correct it. But I am still concerned that it exists.
If we spend our time to post on your issues, it would be nice, if you read the last entries in this thread exactly. Yes, it is a bug. But it is not related to the bug, you mentioned, and if you look at my sample document and read carefully, what I wrote about breakpoints and browser width, the bug is avoidable.
If you don’t want to modify your layout, you have to wait, until a bug fix is released.
Hi Gunter, your screenshot shows a breakpoint not included in the discussion. It only displays messed up like that, because I deleted the other breakpoints.
Why don’t you delete these elements? This would save such a of time in analysing a file. What can I do more, than ask for this, as I did: "Give us a corrected .muse file. But please, please, please: Only the index page, without any element, which don’t affect your issue. If you don’t reduce your site this way, we have to do it – and this will reduce our time for the issues of other users."
Copy link to clipboard
Hi folks. I noted that the same bug happens when you have a layout of elements over a stretch to width container, so this bug which appears since the latest release is not limited to composition widgets. Thought yoi should know.
is there any idea of next bug release?
Hi Gunter. Here is a muse file with none other than the offending elements in a layout.
An image, a button and a text box, all in fixed breakpoint - sitting on a rectangle container which is stretch to browser width.
Note the appearance of white box on right and horizontal scroll bar.
This is the same apparent situation I had with the composition over a rectangle background, stretched to browser width.
Hope this helps.
Also, in addition - I note that a horizontal scroll bar also appears on a completely blank site and wonder if this is normal.
This scroll bar is much shorter appearance but it appears between 1270 and 1253px.
I'm thinking that is not right?
• Horizontal shift: Yes, the issue appears in this case too – but obviously only in Chrome. It is the same bug, and i think, this additional informations is quite valuable for the engineering team.
• Scrollbar issues: Here all reacts completely correct:
On Safari and Chrome for Mac I cant see a horizontal scrollbar.
What I can see, is a vertical scrollbar in your smallest breakpoint, where the minimal page height is set to 1300 px, what is higher than most screens and ends up in showing a vertical scrollbar.