Closed Bug 1472465 Opened Last year Closed Last year

Incorrect CSS hover behaviour on large draggable elements


(Core :: Web Painting, defect, P2)




Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- wontfix
firefox62 + verified
firefox63 --- verified


(Reporter: mail, Assigned: miko)



(Keywords: regression)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180621125625

Steps to reproduce:

Page that demonstrates the problem:

The page shows a draggable map in a frame. The map has a series of coloured dots that you can click to open different photos.

Load the map and DRAG it to show a part of the map NOT INITIALLY shown. Hover over the small coloured dots on the map.

Actual results:

The dots are CSS styled to be partially transparent until you hover over them. Then they turn to solid color. This works fine on the initial part of the map when you load the page, but when you drag the map to show other parts of the map and other coloured dots, these dots do not change to solid colour when you hover over them the FIRST time. The SECOND time you hover over the dots, they correctly turn solid.

Expected results:

The dots should turn solid the first time you hover over them.

They used to turn solid without problems in earlier versions of Firefox. I have tested the page in Edge 42.17134.1.0 and Google Chrome 67.0.3396.99 and they both display correct behaviour.

It seems as if Firefox only registers the dots initially visible in the map, and it only seems to "notice" the remaining dots - the dots that appear when you drag the map - once you have hovered above them once.

An interesting detail is, that if you load the map, drag it somewhere else to show new dots, type a new URL (to go to a different page) and then press the back arrow to go back to the map, ALL dots in whatever part of the map you were at now function correctly (that is, until you drag the map somewhere else).
The same thing happens if you drag the map, choose a different tab and then go back to the tab containing the map.

In other words: Whenever the map is displayed it seems to render correctly in the sense that all coloured dots behave correctly, but as soon as the map is dragged, the dots are "forgotten" until you hover above them once, or the whole page is re-rendered (using tabs or back button).
I have examined the problem further and have found behaviour that hopefully can help identifying the problem:

The problem where the buttons fail to light up when hovering above them seemed to be connected to either the AMOUNT of buttons on the draggable map (image) or to the SIZE of the draggable map (image).

For instance, this map - (measuring 1928 x 1550 pixels) - behaves correctly, whereas this map - (measuring 2476 x 1695 pixels) - doesn't behave as it should.

I did a little test by taking a large map (2991 x 2309 pixels) and greatly reducing the amount of buttons (all the way down to four buttons - two visible on load and two hidden outside the visible area). The problem still persisted. The test map can be found here:

In other words, the bug causing incorrect CSS behaviour for the buttons placed on the draggable map is not connected to the amount of buttons/elements but to the SIZE of the draggable element.

Just to make sure, I checked whether the bug could be connected to screen resolution (that is, whether it was because the draggable element was bigger than the screen size), but my resolution is 1920 x 1200 which is smaller than all linked maps above (both the one working and the two not working).
Summary: CSS hover needs two mouseovers on draggable element → Incorrect CSS hover behaviour on large draggable elements
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID:20180703220118

Managed to reproduce the issue on Windows 10 x64 using the latest Nightly 63.0a1,Firefox Beta 62.0b5 and Firefox Release 61.0.
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Product: Firefox → Core
Version: 61 Branch → Trunk
I can reproduce this on macOS with the steps provided by the reporter.

It seems that when a dot is moved into the view, the first flipping of opacity is not effective. This can be observed even with inspector open and have the opacity property manually disable and reenable from the rule view.

From the inspector, I believe the property is correctly applied, so I would suspect it is either a Graphics issue (likely layer-related) or Web Painting issue.
Component: CSS Parsing and Computation → Graphics: Layers
Priority: -- → P2
With any luck, it's the same root cause as bug 1471181.
Flags: needinfo?(mikokm)
Hi Miko, Can I assign this to you under the assumption that it is the same room cause as bug 1471181 (the one you're already assigned)?  If it's not the same root cause, can you needinfo me back to find another owner?  Thanks!
Assignee: nobody → mikokm
This sounds like a clipping or invalidation issue. Will investigate more along with the bug 1471181.
Flags: needinfo?(mikokm)
This bug was caused by a combination of moving an element with opacity, and then changing the opacity value.

Because the children of a flattened inactive nsDisplayOpacity handle their own bounds invalidation, nsDisplayOpacityGeometry returns an empty invalidation region, if the opacity value stays the same. Empty invalidation region prevented the geometry from being updated. This caused nsDisplayOpacityGeometry to invalidate a wrong region, when the actual opacity value of the item was later changed.

This patch forces nsDisplayOpacityGeometry to always get updated, if the inactive nsDisplayOpacity has been flattened.
Comment on attachment 8992221 [details]
Bug 1472465 - Update flattened nsDisplayOpacity geometry despite empty invalidation region
Attachment #8992221 - Flags: review?(matt.woodrow) → review+
Pushed by
Update flattened nsDisplayOpacity geometry despite empty invalidation region r=mattwoodrow
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Duplicate of this bug: 1471181
I am assuming we want to uplift this due to bug 1471181?
Flags: needinfo?(ryanvm)
That would be nice indeed, yes :)
Flags: needinfo?(ryanvm)
Flags: needinfo?(mikokm)
Flags: in-testsuite+
Comment on attachment 8992221 [details]
Bug 1472465 - Update flattened nsDisplayOpacity geometry despite empty invalidation region

Approval Request Comment
[Feature/Bug causing the regression]: Invalidation issues caused by flattening of inactive nsDisplayOpacity items, bug 1442190.
[User impact if declined]: Web elements with opacity, that are moved, and then change opacity, might no get repainted correctly. Most noticeable regression would be Twitter reply button, bug 1471181.
[Is this code covered by automated tests?]: Yes, a new reftest has been added.
[Has the fix been verified in Nightly?]: Yes, I have verified that the bug is not present in Nightly.
[Needs manual test from QE? If yes, steps to reproduce]: No.
[List of other uplifts needed for the feature/fix]: Bug 1472830 added a way to check how the opacity was flattened.
[Is the change risky?]: Low risk. 
[Why is the change risky/not risky?]: The patches are simple and easy to reason about.
[String changes made/needed]: No.
Flags: needinfo?(mikokm)
Attachment #8992221 - Flags: approval-mozilla-beta?
Comment on attachment 8992221 [details]
Bug 1472465 - Update flattened nsDisplayOpacity geometry despite empty invalidation region

Fix for recent regression, includes new tests. 
Let's uplift for beta 10.
Attachment #8992221 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
I’ve reproduced this issue on Firefox 63.0a1 (2018-06-30) under Windows 10 x64.
It is no longer reproducible on Firefox 63.0a1 (2018-07-22) and 62.0b10 (20180719140244) under Windows 10 x64, macOS 10.13 and Ubuntu 16.04 x32.
Flags: qe-verify+
Duplicate of this bug: 1478425
You need to log in before you can comment on or make changes to this bug.