opening bug in new tab is scrolled down
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox118 | --- | wontfix |
firefox119 | --- | wontfix |
firefox120 | --- | wontfix |
firefox121 | --- | wontfix |
firefox122 | --- | wontfix |
firefox123 | --- | wontfix |
firefox124 | --- | fix-optional |
People
(Reporter: tnikkel, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Open Firefox for Android.
Do a bugzilla search with a lot of results. Zoom in and scroll down the list. Open a bug in a new tab. Wait a few seconds. Switch to the new tab with the bug you just opened. It will be scrolled down.
Reporter | ||
Comment 1•2 years ago
|
||
I wonder if this is caused by bug 1853078 somehow.
Comment 2•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
I wonder if this is caused by bug 1853078 somehow.
Do you have a theory for a plausible connection between the two? Like are you thinking maybe there's some script on BMO that uses window.innerHeight
and is observing the incorrect value seen in bug 1853078?
Reporter | ||
Comment 3•2 years ago
|
||
Nothing specific, just that the conditions "opened in background tab on Android" are both the same and decently specific.
Comment 4•2 years ago
•
|
||
Setting P3:S3 since it seems to be our bugzilla specific. I tried it on a modified version of the test case in bug 1853078 and tried on bugs.webkit.org, I don't see the issue there.
Comment 5•2 years ago
|
||
I've encountered same issue. Also i suspected the same bug 1853078 may be related.
Comment 6•2 years ago
•
|
||
jackyzy823, thanks for the information.
From bug 1854876 comment 0.
It was not reproducible before Firefox 116.
So this is definitely a regression.
Reporter | ||
Comment 8•2 years ago
|
||
Oh yeah, it probably is a regression, that means mozregression could be useful. I didn't think of that before.
Comment 9•2 years ago
|
||
I've done some bisection.
Fenix Nightly
- The last good 2023-07-17-16-01-30 GV: 20230716213402 MozillaCentral: 2d64faa1590722f6ec14781ee5e175a2c875171c
- The first bad 2023-07-18-04-01-21 GV: 20230717160307 MozillaCentral: 89d21fac92b8f98201b8715c6c050aace4b46afb
A quick glance at https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2d64faa1590722f6ec14781ee5e175a2c875171c&tochange=89d21fac92b8f98201b8715c6c050aace4b46afb
The most suspicious one https://hg.mozilla.org/mozilla-central/rev/f02a0e3200b02854e3c7c3f532640ef5c82e6d64 for bug 1842679
Reporter | ||
Comment 10•2 years ago
|
||
Thanks! That does seem like a good candidate. I'll mark it and we can change it if it turns out to be something else.
Comment 11•2 years ago
|
||
Set release status flags based on info from the regressing bug 1842679
:dlrobertson, since you are the author of the regressor, bug 1842679, could you take a look?
For more information, please visit BugBot documentation.
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Set release status flags based on info from the regressing bug 1842679
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Local testing seems to indicate that this is caused by the same thing that causes bug 1858984. I'll leave this open and run through the STR once the patch that fixes bug 1858984 makes it to nightly.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
•
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #13)
Local testing seems to indicate that this is caused by the same thing that causes bug 1858984. I'll leave this open and run through the STR once the patch that fixes bug 1858984 makes it to nightly.
Looks like bug 1858984 was fixed a few weeks back, so maybe this is fixed -- Dan and/or Timothy, could you retest and see if we can close this?
Updated•2 years ago
|
Comment 15•2 years ago
|
||
I just re-tested this, and can still reproduce the issue.
Updated•2 years ago
|
Description
•