The page is visible behind fullscreen element after displayport expires
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: csheany, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [geckoview:p2])
Attachments
(4 files)
Comment 3•6 years ago
|
||
Comment 5•6 years ago
|
||
Updated•6 years ago
|
Reporter | ||
Comment 10•6 years ago
|
||
Reporter | ||
Comment 11•6 years ago
|
||
Comment 12•6 years ago
|
||
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
Comment 15•6 years ago
|
||
Reporter | ||
Comment 16•6 years ago
|
||
Comment 18•6 years ago
|
||
Comment 19•6 years ago
|
||
Comment 20•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Reporter | ||
Comment 21•6 years ago
|
||
Reporter | ||
Comment 22•6 years ago
|
||
Updated•6 years ago
|
Comment 23•6 years ago
|
||
Comment 24•6 years ago
|
||
Reporter | ||
Comment 25•6 years ago
|
||
Comment 26•6 years ago
|
||
Comment 27•6 years ago
|
||
Comment 28•6 years ago
|
||
Comment 30•6 years ago
|
||
It's something I can investigate, but my queue is full with other higher-priority tasks, so it will be a while before I get to this.
Reporter | ||
Comment 31•6 years ago
|
||
I think I tracked down the regression.
The last good build was Nightly 54.0a1 (2017-02-02)
The first bad build was Nightly 54.0a1 (2017-02-03)
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f985243bb630&tochange=2aede0a97bc6
Would you mind taking a quick look?
Comment 32•6 years ago
|
||
Thanks for getting a regression window.
In that window, bug 1298218 jumps out as a potential regressing bug, as it is a significant change and has caused a number of other scrolling-related regressions over time. I'm tentatively marking this as blocking bug 1298218 and needinfoing Markus.
Reporter | ||
Comment 33•6 years ago
|
||
Matt or Timothy, would either of you mind taking a look?
Comment 34•6 years ago
|
||
Botond, are you able to check if this is fixed by containerless scrolling for Android?
Comment 35•6 years ago
|
||
Testing on https://bugzilla.mozilla.org/attachment.cgi?id=9018847, I can reproduce the issue in the latest nightly, and not with containerless scrolling, so yes, I would say this is potentially fixed by containerless scrolling.
Comment 36•6 years ago
|
||
Great, let's wait for that to land then, rather than investing time into debugging code we're trying to get rid of.
Updated•6 years ago
|
Reporter | ||
Comment 38•6 years ago
|
||
Restoring the flag to get your thoughts.
Updated•6 years ago
|
Comment 39•6 years ago
|
||
No thoughts needed. This is waiting for containerless scrolling.
Reporter | ||
Comment 40•6 years ago
|
||
I understand the logic.
I was just thinking about the releases without it while it rides the trains.
Also, what is the purpose of displayport expiration?
Comment 41•6 years ago
|
||
(In reply to csheany from comment #40)
I was just thinking about the releases without it while it rides the trains.
We're not going to fix it in those releases. It's not a good use of time to try doing that, as we have a lot of other things that need fixing too.
Also, what is the purpose of displayport expiration?
To save memory when the user is not actively scrolling. Having a displayport on a scrollframe uses up a bunch of memory.
Reporter | ||
Comment 42•6 years ago
|
||
I guess a part of me wants to hear what he has to say.
Here's to Nightly 67.0a1 (2019-03-08) :)
Comment 43•6 years ago
|
||
I agree with kats, containerless scrolling is the "right" way to fix this, and it's happening.
Reporter | ||
Comment 44•6 years ago
|
||
Thank you Markus :)
Comment 45•6 years ago
|
||
As I mentioned in bug 1500719 comment 34, I tested layout.scroll.root-frame-containers
(flip it back and forth in nightly) and it seems to me that containerless scrolling does fix this issue.
Comment 46•6 years ago
|
||
(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #45)
As I mentioned in bug 1500719 comment 34, I tested
layout.scroll.root-frame-containers
(flip it back and forth in nightly) and it seems to me that containerless scrolling does fix this issue.
Given that Containerless scrolling landed with 67, I am going to mark this bug as fixed.
Reporter | ||
Comment 47•6 years ago
|
||
I wish that were the case but unfortunately not yet.
Comment 48•6 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #35)
Testing on https://bugzilla.mozilla.org/attachment.cgi?id=9018847, I can reproduce the issue in the latest nightly, and not with containerless scrolling, so yes, I would say this is potentially fixed by containerless scrolling.
Re-testing on the same page, I can confirm that this still affects recent nightlies, even though we now have containerless scrolling.
It would be interesting to find out what regressed it with containerless scrolling enabled.
Comment 49•6 years ago
|
||
Happy to take a patch for 70 but since this is triaged and set to P3 priority I'm setting it as fix-optional.
That will remove the bug from weekly regression triage.
Updated•5 years ago
|
Comment 51•3 years ago
|
||
Is anyone still experiencing this issue?
I tried the test page from comment 21, as well as those in the two duplicate bugs (bug 1384512 and bug 1560818), in recent Fenix and GeckoView Example, and could not reproduce them. (I also tried using mozregression to see what fixed it, but it looks like builds only go back one year, and GVE from one year ago does not exhibit the bug either.)
Comment 52•3 years ago
|
||
It doesn't seem that I can reproduce this issue now either.
Comment 53•3 years ago
|
||
maybe this got fixed when releasing Fenix (no Bugfix commit, just different code)
Comment 54•3 years ago
|
||
Let's close this. If anyone can still reproduce it in a recent Fenix version, please chime in and we can reopen.
Updated•3 years ago
|
Description
•