850690 - Gap at the top of the document with dynamic toolbar enabled

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Readability, defect)

Description

[Scott Johnson (:jwir3)]

Attachment: screenshot 1

STR:

1) Turn on reflow on zoom.
2) Load the following page: http://people.mozilla.org/~sjohnson/junkyard/lemis.html as the first tab in the browser (don't navigate to another page and then navigate to the test page - load the test page first).
3) Notice how, at the top of the page, there is a blank area (see screenshot 1). Notice further how the blank area cannot be scrolled away (see screenshot 2).

ER:
See screenshot 3. Note that this happens after either reloading the page, or loading another page initially and then loading the lesmis page. 

I think that this has something to do with interaction between the location-bar hiding stuff, bug 716403, (since it seems to be in the general location and have the same size as the location bar), this specific page (since it doesn't happen on every page), and the reflow-on-zoom stuff (since it doesn't happen with reflow-on-zoom disabled).

Comment 1

[Scott Johnson (:jwir3)]

Attachment: screenshot 2

Comment 2

[Scott Johnson (:jwir3)]

Attachment: screenshot 3

Comment 3

[Scott Johnson (:jwir3)]

Correction:

Expected results don't happen just with a reload of the page. It requires that reflow-on-zoom be disabled, and then re-enabled. Disabling reflow-on-zoom makes the problem go away, even without a reload.

Oddly enough, I've observed that on the first load of the page (when this bug is reproducible), it shows the location bar momentarily and then the location bar slides up and out of view. The blank space is present even when the location bar is visible.

Comment 5

[Chris Lord [:cwiiis]]

This is an odd one. Some notes;

Because the shadow and page background colour still draw correctly, this shows us that Java's idea of the surface size is still correct.

That input seems to be offset by the toolbar size, and that the gap is toolbar size indicates to me that a window resize has gotten swallowed somehow - the gap, shadow, and offset indicate that the surface is smaller than it should be, but Java doesn't know about it. If Java doesn't know about it, this would indicate that a window resize event got swallowed somewhere.

This theory is further backed by forcing a page resize 'fixing' the issue (for example, causing the keyboard to open, either by focusing a form element, or by tapping the awesomebar and going back).

Comment 6

[Chris Lord [:cwiiis]]

So I see this regardless of reflow-on-zoom, as I described in bug 850759 - I'll take this. Likely a bad rebase/conflicting change, this didn't use to happen...

Comment 7

[Wesley Johnston (:wesj)]

I'm seeing this on https://app.shootq.com/public/~6444e/clients/reset as well.

Comment 8

[Chris Lord [:cwiiis]]

Seems to be completely independent of site.

Comment 9

[Chris Lord [:cwiiis]]

So this is happening because for some reason the layer manager ends up with a stale width/height (even though I've verified the resize event gets sent correctly) - possibly a bad/missing compositor resume?

Should have this fixed pretty soon.

Comment 10

[Chris Lord [:cwiiis]]

Looks like this is caused by bug 797942 interacting badly with bug 844275. The former should no longer be necessary after the latter, I'm just pushing some try builds to make sure.

Comment 11

[Chris Lord [:cwiiis]]

Attachment: Backout bug 797942

I won't push until try comes back nice and green. Or at least as green as it ever is.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 725410 [details] [diff] [review]
Backout bug 797942

Review of attachment 725410 [details] [diff] [review]:
-----------------------------------------------------------------

r=me if this is fine on try

Comment 14

[Kartikaya Gupta (email:[e-mail])]

Also CC'ing gbrown as an FYI

Comment 15

[Chris Lord [:cwiiis]]

https://tbpl.mozilla.org/?tree=Try&rev=be821a065fd8 - This looks green enough to me, pushed to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/a71c3f178d91

Comment 16

[Chris Lord [:cwiiis]]

Attachment: translate-pattern-1.svg fuzzing

Looks like this caused a random alignment change again (we need to track this down at some point, I'll file a bug next week...) - Got r=jwatt and pushed to avoid backout.

https://tbpl.mozilla.org/?tree=Try&rev=60e12e08cefd

Comment 17

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/0f15f3f1ec62

Comment 18

[Geoff Brown [:gbrown]]

Causes intermittent robocop failures -- see https://bugzilla.mozilla.org/show_bug.cgi?id=851861#c20. Sorry!

Comment 19

[Chris Lord [:cwiiis]]

This hasnt been backed out, has it? If not (I hope not...), this should remain closed and we should continue tracking in bug 851861.

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Was this backed out?  If it was, please include a changeset link when reopening.  If it wasn't, please don't reopen -- the status of the bug should reflect whether the fix is in mozilla-central.

Comment 21

[Geoff Brown [:gbrown]]

No, was not backed out.