Pages don't fit the screen upon loading
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
People
(Reporter: csheany, Unassigned)
References
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:66.0) Gecko/66.0 Firefox/66.0
Steps to reproduce:
- Open planet.mozilla.org
Actual results:
The page is smaller than the screen
Expected results:
The page should take up the width
Comment 1•6 years ago
|
||
One of the recent viewport handling changes presumably.
Because this probably depends on the current content [1] and loading the page from the Internet Archive gives an XML-error, I've temporarily archived the page as it appeared today here: http://www.buttercookie.de/temp/Planet%20Mozilla%202019-01-20.xhtml
[1] Most probably the code snippet you get when you search for "The complete solution", although there are probably a few more very long lines scattered throughout the document.
It almost seems like a test case for Bug 1510029.
Comment 5•6 years ago
•
|
||
This is an intended consequence of bug 1423709. The initial zoom level now matches Chrome's behaviour.
The page appears to be zoomed out more than it should be, because most of the contents are a fixed width, but there is content further down which is wider, and we are basing the zoom on the total width.
Perhaps the website could be better constructed, so that posts with wide content are wrapped in a horizontally scrollable div, rather than widening the entire document. However, that's not a browser issue. (You're welcome to file an issue against the planet.mozilla.org site about that.)
Unlike mozilla.org/en-us/firefox the right half can't be scrolled.
Also, once adjusted page can't be zoomed out to the initial state.
This brought to mind Bug 1509552 however doesn't require rotating.
Comment 7•6 years ago
|
||
Hmmm - you're right, in a nightly build, the page loads zoomed out even further than in Chrome, then when you zoom in (sometimes also if you just scroll) the zoom snaps to the higher (correct) value, and you can't go back.
Bug 1510214 improved the behaviour here (it was even worse prior to that), which might suggest that the initial incorrect zoom level is chosen without regard to the content width.
What's strange, is that I can't reproduce this in a debug build. Perhaps it's timing-related, and the debug build is too slow to trigger it.
Anyways, let's reopen while we investigate further.
Comment 8•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #7)
Bug 1510214 improved the behaviour here (it was even worse prior to that), which might suggest that the initial incorrect zoom level is chosen without regard to the content width.
Another possibility is that the content width changes during / shortly after page load, from something wider to something less wide, and the change somehow fails to trigger a zoom recomputation.
Comment 9•6 years ago
|
||
Reproduced in a local opt build.
(In reply to Botond Ballo [:botond] from comment #8)
Another possibility is that the content width changes during / shortly after page load, from something wider to something less wide, and the change somehow fails to trigger a zoom recomputation.
This is indeed what seems to be happening. The initial zoom is based on a content width of 3735px, and later when something like a toolbar transition triggers a reflow, the content width changes to 1240px.
Reporter | ||
Comment 10•6 years ago
|
||
Why does a toolbar transiton change the width?
Comment 11•6 years ago
|
||
(In reply to csheany from comment #10)
Why does a toolbar transiton change the width?
I don't think the toolbar transition is causing the change in width; it just triggers the zoom updating code which notices that the width has changed.
I haven't tracked down yet the cause of the change in width.
Reporter | ||
Comment 12•6 years ago
|
||
I meant in general. I thought it would only change the height.
Comment 13•6 years ago
|
||
(In reply to csheany from comment #12)
I meant in general. I thought it would only change the height.
The zoom updating code runs in response to any change in size to the browser's content area, even if it's just a change in height.
I'm not knowledgeable enough about CSS to say whether it's possible for a change in the height of the browser's content area to change to the resulting content width, but it doesn't really matter for this bug.
Comment 14•6 years ago
|
||
diagnosis |
I think what's happening here is "interruptible reflow". For a very long page like planet.m.o, reflowing the page can take a long time, so we interrupt the reflow periodically to paint the page so the user can see some content without waiting for the reflow to complete.
However, the zoom updating code isn't hooked up to this mechanism: it's triggered when the reflow is initiated, and if the reflow is not interrupted, it observes the reflow's final results. If the reflow is interrupted, it observes the reflow's partial result before the first interruption (which in this case is the wider 3735px content width), and chooses the zoom based on that. When the reflow finishes and the final result is available (in this case, the content width of 1240px), no one is triggering the zoom updating code to reflect the new content width.
(This also explains why the bug is sensitive to timing: the decision to interrupt reflow is based on a timer that measures time since the last paint.)
It looks like Hiro has some code to hook this up in bug 1519013; I expect that will fix this.
Reporter | ||
Comment 15•6 years ago
|
||
I didn't mean the content width but the viewport.
I notice the APZ Mini Map resizing despite a page being zoomed and was curious about that.
Reporter | ||
Comment 16•6 years ago
|
||
I don't think contents are overflowing.
With the toolbar set not to hide I don't notice elements outside the page.
What sets the content width based initial zoom?
Perhaps that is what needs to change.
Comment 17•6 years ago
|
||
(In reply to csheany from comment #15)
I didn't mean the content width but the viewport.
There are four sizes of interest here:
- The visual viewport size
- The initial containing block size
- The content size
- The layout viewport size
I list them in this order, because each one potentially depends on the ones above it.
A dynamic toolbar transition will not change (1) or (2). It may change (3) on some pages (I'm not sure), and therefore potentially also (4).
I notice the APZ Mini Map resizing despite a page being zoomed and was curious about that.
If you'd like me to satisfy your curiosity, you'll need to give more details (what is the page, what are you doing, which color rectangle on the minimap is changing in a way you don't expect, etc.) :)
Comment 18•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #17)
(In reply to csheany from comment #15)
There are four sizes of interest here:
- The visual viewport size
- The initial containing block size
- The content size
- The layout viewport size
I list them in this order, because each one potentially depends on the ones above it.
A dynamic toolbar transition will not change (1) or (2). It may change (3) on some pages (I'm not sure), and therefore potentially also (4).
(Correction: it will not change the width of (1) or (2). Obviously, it's changing the height of (1)).
Reporter | ||
Comment 19•6 years ago
|
||
On mozilla.org/en-us/firefox when scrolling to hide the toolbar the whole minimap (the green rectangle in partciular) expands.
Reporter | ||
Comment 20•6 years ago
|
||
FWIW, this is how the page from Bug 1510214 loads (hg.mozilla.org/try/rev/acb07b97fa8ed79112e86e5454b37a3e50593e12)
Reporter | ||
Comment 21•6 years ago
|
||
Reporter | ||
Comment 22•6 years ago
|
||
Compared to...
Reporter | ||
Comment 23•6 years ago
|
||
Comment 24•6 years ago
|
||
(In reply to csheany from comment #19)
On mozilla.org/en-us/firefox when scrolling to hide the toolbar the whole minimap (the green rectangle in partciular) expands.
This is an artifact of how we are sizing the minimap: we try to have its aspect ratio match the aspect ratio of the page content. When the dynamic toolbar hides, we have space to expand the minimap vertically, and to preserve the aspect ratio, we also expand it horizontally a bit.
Comment 25•6 years ago
|
||
(In reply to csheany from comment #20)
FWIW, this is how the page from Bug 1510214 loads (hg.mozilla.org/try/rev/acb07b97fa8ed79112e86e5454b37a3e50593e12)
Are the screenshots from comment 21 and comment 23 from different builds? Or the same build but different steps?
Reporter | ||
Comment 26•6 years ago
|
||
The same build.
Comment 21 is initial.
Comment 23 is the same page zoomed in to how other pages without "out of reach" content loads.
Comment 27•6 years ago
|
||
Ok, thank you for clarifying.
So far, everything I've seen is consistent with the diagnosis in comment 14.
Comment 28•6 years ago
|
||
(In reply to csheany from comment #16)
I don't think contents are overflowing.
With the toolbar set not to hide I don't notice elements outside the page.
I think I understand the confusion here: even though bug 1519013 mentions "overflowed contents" in the title, the patch there is making changes to interruptible reflow that affect all pages, not just pages that were affected by bug 1423013. So, it will affect pages like planet.mozilla.org as well.
Comment 29•6 years ago
|
||
(Or, to be technical: pages like planet.mozilla.org do contain overflowed content, in the sense that the content width overflows (is larger than) the initial containing block width. They're just not overflow: hidden
, and so were not affected by bug 1423013.)
Comment 30•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #7)
Hmmm - you're right, in a nightly build, the page loads zoomed out even further than in Chrome, then when you zoom in (sometimes also if you just scroll) the zoom snaps to the higher (correct) value, and you can't go back.
I've been experiencing this problem a fair bit on TreeHerder. It seems pretty bad in that it breaks scrolling to parts of the page. I have to zoom out all the way before it will reset and let me scroll. Making this a P2.
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Comment 31•6 years ago
|
||
Is here a TreeHerder url I can test?
Comment 32•6 years ago
|
||
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #30)
I've been experiencing this problem a fair bit on TreeHerder. It seems pretty bad in that it breaks scrolling to parts of the page. I have to zoom out all the way before it will reset and let me scroll. Making this a P2.
I believe the "breaks scrolling to parts of the page" (and with it the P2-ness) has been fixed by bug 1531057.
Reporter | ||
Comment 33•6 years ago
|
||
I actually thought you were going to report my findings at...
https://bugs.chromium.org/p/chromium/issues/detail?id=933931
Reporter | ||
Comment 34•6 years ago
|
||
Why is it off topic?
It is another site where I am able to reproduce this bug.
Comment 32 was made while testing Bug 1531233 I just didn't respond sooner.
Reporter | ||
Comment 35•6 years ago
|
||
Comment 36•6 years ago
|
||
comment 32 (and this bug in general) have nothing to do with bug 1531233.
Bug 1531233 is related to flexbox.
This bug (including comment 32) is related to viewport management.
Reporter | ||
Comment 37•6 years ago
|
||
Of course.
Investing Bug 1531233 led to the Chromium bug and when I opened the page I ran into this bug.
How does it load on a tablet for you?
Comment 38•6 years ago
|
||
(In reply to csheany from comment #37)
Of course.
Investing Bug 1531233 led to the Chromium bug and when I opened the page I ran into this bug.
Ok, thanks.
How does it load on a tablet for you?
I will test it together with the testcase from comment 0, when I get to working on this bug, after the dependent bug 1519013 is resolved.
Reporter | ||
Comment 39•6 years ago
|
||
Are we on the same "page"? :)
Would you mind removing the off-topic?
Comment 40•6 years ago
|
||
(In reply to csheany from comment #39)
Would you mind removing the off-topic?
Done. I think the reason we were confused is that comment 33 sounded like you were suggesting that I (or someone) post a comment to that Chromium bug.
Reporter | ||
Comment 41•6 years ago
|
||
Thank you.
The timing was just a coincidence which is why I posted the screenshot.
Comment 42•6 years ago
|
||
I retested this with today's nightly, and I no longer see this issue. I expect this was fixed by bug 1519013.
Charles, could you confirm that this is fixed for you?
Reporter | ||
Comment 43•6 years ago
|
||
I am unfortunately still seeing the issue.
Are you testing with a phone/ tablet or both?
Bug 1519013 did fix Comment 33.
I wonder if only a specific content width was affected.
FWIW the page loads properly in Focus with WebView on the same device.
Comment 44•6 years ago
•
|
||
I did test both phone and tablet, and I tested Chrome as well. The initial zoom level chosen by Firefox matches Chrome on both devices.
I do see that Focus+WebView chooses a larger initial zoom level (different from Chrome). I don't know why that is, but I would consider that a bug in Focus+WebView, not a bug in Firefox.
Comment 45•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #44)
I do see that Focus+WebView chooses a larger initial zoom level (different from Chrome). I don't know why that is, but I would consider that a bug in Focus+WebView, not a bug in Firefox.
Last time I tried it (which admittedly is a little while ago), Focus+WebView hadn't enabled WebView's <meta viewport> handling, so desktop pages like Planet Mozilla would be rendered with an implicit "width=device-width" instead of the special desktop mode viewport width like Chrome or Firefox.
Comment 46•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #44)
I do see that Focus+WebView chooses a larger initial zoom level (different from Chrome). I don't know why that is, but I would consider that a bug in Focus+WebView, not a bug in Firefox.
To be clear, I do appreciate that on this page, the initial zoom level chosen by Focus+WebView is the one that makes the page's content more readable.
However, the zoom level chosen by Firefox and Chrome is based on a consistent set of rules that apply to all pages. On this page, it happens to produce this unfortunate result, because the page has really wide content (gigantic images) further down.
While I don't know the exact reason why Focus+WebView chooses the larger zoom level, I'm sure it's not because it has more sophisticated logic than Firefox and Chrome. It's just applying a different set of rules, which happen to produce a better outcome on this page, but likely produce worse outcomes on other pages.
It's possible that the planet.mozilla.org site could be structured better, to avoid having content that's so much wider than the text in the blog posts. However, that's out of scope for this bug.
Comment 47•6 years ago
|
||
(In reply to Jan Henning [:JanH] from comment #45)
(In reply to Botond Ballo [:botond] from comment #44)
I do see that Focus+WebView chooses a larger initial zoom level (different from Chrome). I don't know why that is, but I would consider that a bug in Focus+WebView, not a bug in Firefox.
Last time I tried it (which admittedly is a little while ago), Focus+WebView hadn't enabled WebView's <meta viewport> handling, so desktop pages like Planet Mozilla would be rendered with an implicit "width=device-width" instead of the special desktop mode viewport width like Chrome or Firefox.
Thanks, that does explain Focus+WebView's behaviour, and why it's different from Firefox and Chrome.
Reporter | ||
Comment 48•6 years ago
|
||
May I ask what rules you are referring to?
Comment 49•6 years ago
|
||
(In reply to csheany from comment #48)
May I ask what rules you are referring to?
They are summarized in the viewports explainer doc but basically it's "zoom out as far as possible, subject to a minimum of 0.25, unless the page specifies an initial-scale
in which case use that".
Reporter | ||
Comment 50•6 years ago
|
||
Can you provide an example where that is benefical?
Are rules meant to be broken? :)
Comment 51•6 years ago
|
||
(In reply to csheany from comment #50)
Can you provide an example where that is benefical?
On more typical pages, the content is the same width throughout the page (as opposed to most content being narrow, and a few images being very wide, as currently on planet.mozilla.org).
In such cases, it's helpful to see the entire content width at once upon loading, to make sure you don't e.g. miss some controls / useful information that's scrolled out of view at the right edge.
For specific examples where users have complained about the previous behaviour, see the webcompat issues linked to bug 1423709 (for example, this one).
Are rules meant to be broken? :)
Sometimes, with good reason. :) In this case, the consistent request from the web compat team has been to reach parity with Chrome's behaviour.
Comment 52•6 years ago
•
|
||
Anyway, I'm going to close this because the part that was an actual bug:
(In reply to Botond Ballo [:botond] from comment #7)
Hmmm - you're right, in a nightly build, the page loads zoomed out even further than in Chrome, then when you zoom in (sometimes also if you just scroll) the zoom snaps to the higher (correct) value, and you can't go back.
was fixed by bug 1519013.
If you have further comments about the general issue of pages loading at their minimum zoom level, the best place to have a discussion about that is probably in an issue for the explainer doc. The Firefox behaviour is unlikely to change in that respect unless there is consensus among other browser implementers in such an issue.
Description
•