Closed Bug 1568826 Opened 5 years ago Closed 5 years ago

Effective position of buttons and boxes doesn't match their visual placement after scrolling down

Categories

(Core :: Panning and Zooming, defect)

Product:
Core
Component:
Panning and Zooming
Version:
68 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 69+ fixed
firefox68 --- wontfix
firefox69 --- fixed
firefox70 --- fixed

People

(Reporter: jens.reyer, Assigned: botond)

References

(Regression)

Details

(Keywords: regression, Whiteboard: Regression)

Attachments

(1 file)

Bug 1568826 - Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel
47 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
jcristau
: approval-mozilla-esr68+
Details | Review

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

REGRESSION in Firefox 68:

I updated Linux Mint 19.1, including firefox 67.0.4+linuxmint1+tessa to 68.0+linuxmint1+tessa.

Now a self-developed webapp (Javascript) misbehaves: I have a page that displays a list with several items that you may e.g. tick/untick, or click buttons to e.g. edit an entry or add a new one.

To reproduce my issue:

I have a somewhat longer list (~ more than double the display height)
AND
I scroll it down
AND
open and close again a "sub-window" (part of the same window/tab) in which we can edit single entries.

Found on Linux Mint 19.1 (amd64).

I can also reproduce this with your Linux amd64 builds in a fresh profile:

Mozilla Firefox 68.0.1 from https://www.mozilla.org/en-US/firefox/download/thanks/

Mozilla Firefox 70.0a1 from https://www.mozilla.org/de/firefox/channel/desktop/#nightly (downloaded 2019-07-24T15:51 CEST)

The same still works fine in firefox (67.0.4+linuxmint1+tessa) and chromium-browser (75.0.3770.90-0ubuntu0.18.04.1).

Bugzilla suggested that this might be a duplicate of these bugs by Treeherder Bug Filer:
https://bugzilla.mozilla.org/show_bug.cgi?id=1561164
https://bugzilla.mozilla.org/show_bug.cgi?id=1562216
https://bugzilla.mozilla.org/show_bug.cgi?id=1564327

Actual results:

The position of the boxes/buttons on the display looks perfectly fine, but doesn't match the position that you actually have to click. If I click a button nothing happens (or something happens which belongs to another button which is positioned above the clicked button).

To get the actually wanted result I have to click about one centimeter below the displayed button/box.

Expected results:

Clicking a button/box should trigger the associated function.

Just noticed:
The misbehavior stops if I scroll up and down again, or switch to another firefox tab and back.
The problem reappears as soon as I scroll and open and close the subwindow again

Hi Jens Reyer!
Could you please send me the url of the website you are using to be able to reproduce it?
Probably if it also happens in chromium-browser it is a problem of the page and not of the Firefox Browser.
Thanks for your cooperation.

Flags: needinfo?(jens.reyer)

Hi Marcela,

thanks for your answer!

tl;dr:

  • The website is not public.
  • mozregression first bad revision: dba3c6692a02d1e874bbdbfae9a8424bb68375d3

Unfortunately the website is not public. We'd have to set up a separate public instance and fill it with fake data, or give trusted developers access to the private instance. I hope we can avoid that.

The website is self-developed with some older Javascript framework which is quite close to standards, and worked fine for years now. As previously stated, the issue occurs after scrolling and opening and closing again a "sub-window". [NEW INFO:] This sub-window is just a rectangle (with some content) drawn within the current firefox window/tab.

I talked to our developer: our assumption (still being worked on) is that we can fix this in our app, by forcing a new rendering of the site after closing the sub-window.

It seems there was a slight misunderstanding about chromium-browser - it is NOT affected:

NOT affected:

  • chromium-browser 75.0.3770.90 (and previous versions)
  • firefox 67 (and previous versions)

Affected:

  • firefox 68 (LinuxMint .deb, official Linux build, and [NEW INFO:] the official Windows build)
  • firefox 70.0a1

[NEW INFO] I did a "mozregression --good=2019-03-18 --bad=2019-05-20"
Last good revision: 1be22e2d35d1e2a40451b2d555ced98a49d533af
First bad revision: dba3c6692a02d1e874bbdbfae9a8424bb68375d3

Clearing the needinfo tag, despite not giving the preferred answer, sorry.
I'm afk the next 2 weeks.

Flags: needinfo?(jens.reyer)

Hi Jens!
It was not possible to reproduce this defect because the url is private.
Could you generate a dummy test case? This would allow us to validate the error and also run the mozregression.
Beyond everything, the bug will be considered as valid
Thanks for your cooperation.

Status: UNCONFIRMED → NEW
status-firefox68: --- → affected
status-firefox69: --- → affected
status-firefox70: --- → affected
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Flags: needinfo?(jens.reyer)
Product: Firefox → Core
Whiteboard: Regression
Version: 68 Branch → Trunk

Thanks for filing and for the regression range :)

So the first bad revision according to your regression range is https://hg.mozilla.org/mozilla-central/rev/dba3c6692a02d1e874bbdbfae9a8424bb68375d3. That is bug 1549625, which sounds plausible.

But without a test-case this is going to be hard to track down indeed. Is there any chance you could construct and attach a test-case that reproduces the bug?

Alternatively maybe Botond has ideas about how could this have regressed?

Component: CSS Parsing and Computation → Panning and Zooming
Flags: needinfo?(botond)
Keywords: regression
Regressed by: 1549625

It seems from the description in comment 0 that APZ hit testing is off. But hard to debug without reproducing it :(

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Alternatively maybe Botond has ideas about how could this have regressed?

I don't know what the exact mechanism is, but the symptoms sound similar to bug 1563938 which was also regressed by bug 1549625.

The solution here is to fix bug 1543485 (which provides an alternative fix for bug 1549625) and then back out the current fix for bug 1549625 which has caused several regressions including this one. This is very high on my priority list.

Depends on: 1543485
Flags: needinfo?(botond)

Actually, maybe there's something better we can do.

Bug 1549625 only affects mobile, but the regressions that have been reported have all been on desktop. We should be able to address the regressions by restricting the existing fix for bug 1549625 to mobile, while we work on the proper fix in bug 1543485 (which is a nontrivial and potentially risky change that I'd rather not uplift).

Assignee: nobody → botond
Flags: needinfo?(jens.reyer)

The fix for bug 1549625 is only necessary in cases where the layout and
visual viewports can diverge (currently mobile, and later desktop zooming),
but it has caused regressions in desktop scenarios that don't involve zooming.

While we can get a proper fix in place (tracked in bug 1543485), restricting
the existing fix to zoomable configurations mitigates the regressions.

Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/39ff0262a9d1
Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel

https://hg.mozilla.org/mozilla-central/rev/39ff0262a9d1

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox70: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

Jens, could you update to the latest nightly and see if the problem is resolved there?

Flags: needinfo?(jens.reyer)

Any plans to backport the workaround for the regression to Firefox 69 and/or 68 ESR? This bug is potentially very confusing to the user. I can confirm it is fixed on latest nightly.

I think this should be pretty safe to backport. Botond, do you agree?

Flags: needinfo?(botond)

Comment on attachment 9082713 [details]
Bug 1568826 - Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel

Beta/Release Uplift Approval Request

  • User impact if declined: On some pages, users can get into a state where the visual position of elements is out of sync with the cursor position, such that clicking actually activates an element farther away from the cursor.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Low risk because this is taking a codepath that was added for the benefit of mobile only, and restricting it to only run on mobile, thereby avoiding undesired side effects on desktop.
  • String changes made/needed:
Flags: needinfo?(botond)
Attachment #9082713 - Flags: approval-mozilla-beta?

Agreed, this is a good candidate for backporting.

Flags: needinfo?(jens.reyer)

Comment on attachment 9082713 [details]
Bug 1568826 - Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel

Minimal patch evaluated to low risk by the team which fixes a regression in 68, approved for 69 beta 12, thanks.

Attachment #9082713 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9082713 [details]
Bug 1568826 - Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: It's a low risk, one liner fix, and it fixes a regression introduced in 68 that causes a range of weird / confusing behaviours on desktop. It would be unfortunate if 68esr users were stuck with these behaviours for the length of the ESR cycle.
  • User impact if declined: On some pages, users can get into a state where the visual position of elements is out of sync with the cursor position, such that clicking actually activates an element farther away from the cursor (and other similar misbehaviour, as e.g. bug 1563938 and bug 1566714).
  • Fix Landed on Version: 70, uplifted to 69
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Low risk because this is taking a codepath that was added for the benefit of mobile only, and restricting it to only run on mobile, thereby avoiding undesired side effects on desktop.
  • String or UUID changes made by this patch:
Attachment #9082713 - Flags: approval-mozilla-esr68?

Comment on attachment 9082713 [details]
Bug 1568826 - Restrict the fix for bug 1549625 to cases where we have a zoomable viewport. r=tnikkel

regression fix, approved for 68.1esr

Attachment #9082713 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

Botond: I successfully tested firefox 69.0b14: now layout and visual viewports always match again. Thanks!

However I noticed that after opening and closing the sub-window (which previously triggered the bug) now the whole window scrolls up a bit.
But although we never noticed this before, I just saw that this also happens with 59.0.2.

Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: