Closed Bug 1521359 Opened 5 years ago Closed 5 years ago

Pages don't fit the screen upon loading

Categories

(Core :: Panning and Zooming, defect, P2)

Product:
Core
Component:
Panning and Zooming
Version:
66 Branch
Platform:
All
Android
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1519013
Tracking Flags:
Tracking Status
firefox66 --- affected
firefox67 --- affected

People

(Reporter: csheany, Unassigned)

References

Details

Attachments

(5 files)

Screenshot_20190117-155917.jpg
217.11 KB, image/jpeg
Details
Screenshot_20190120-093015.jpg
337.75 KB, image/jpeg
Details
Screenshot_20190121-211756.jpg
160.49 KB, image/jpeg
Details
Screenshot_20190121-212011.jpg
329.17 KB, image/jpeg
Details
Screenshot_20190325-130821.jpg
242.00 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Android 7.1.1; Tablet; rv:66.0) Gecko/66.0 Firefox/66.0

Steps to reproduce:

  1. Open planet.mozilla.org

Actual results:

The page is smaller than the screen

Expected results:

The page should take up the width

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.

Status: UNCONFIRMED → NEW
Component: General → Panning and Zooming
Ever confirmed: true
OS: Unspecified → Android
Product: Firefox for Android → Core
Hardware: Unspecified → All
Version: Firefox 66 → 66 Branch

It almost seems like a test case for Bug 1510029.

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.)

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID

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.

Flags: needinfo?(botond)

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.

Status: RESOLVED → REOPENED
Flags: needinfo?(botond)
Resolution: INVALID → ---

(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.

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.

Why does a toolbar transiton change the width?

(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.

I meant in general. I thought it would only change the height.

(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.

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.

Depends on: 1519013

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.

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.

(In reply to csheany from comment #15)

I didn't mean the content width but the viewport.

There are four sizes of interest here:

  1. The visual viewport size
  2. The initial containing block size
  3. The content size
  4. 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.) :)

(In reply to Botond Ballo [:botond] from comment #17)

(In reply to csheany from comment #15)
There are four sizes of interest here:

  1. The visual viewport size
  2. The initial containing block size
  3. The content size
  4. 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)).

On mozilla.org/en-us/firefox when scrolling to hide the toolbar the whole minimap (the green rectangle in partciular) expands.

FWIW, this is how the page from Bug 1510214 loads (hg.mozilla.org/try/rev/acb07b97fa8ed79112e86e5454b37a3e50593e12)

Compared to...

(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.

(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?

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.

Ok, thank you for clarifying.

So far, everything I've seen is consistent with the diagnosis in comment 14.

(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.

(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.)

(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.

Priority: -- → P2

Is here a TreeHerder url I can test?

(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.

I actually thought you were going to report my findings at...

https://bugs.chromium.org/p/chromium/issues/detail?id=933931

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.

Flags: needinfo?(kats)

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.

Flags: needinfo?(kats)

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?

(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.

Are we on the same "page"? :)

Would you mind removing the off-topic?

(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.

Thank you.

The timing was just a coincidence which is why I posted the screenshot.

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?

Flags: needinfo?(csheany)

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.

Flags: needinfo?(csheany)

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.

(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.

(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.

(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.

May I ask what rules you are referring to?

(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".

Can you provide an example where that is benefical?

Are rules meant to be broken? :)

(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.

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.

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: