1472465 - Incorrect CSS hover behaviour on large draggable elements

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P2)

Description

[Jakob Kramer Hero]

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: http://vojensbilleder.dk/byvandring2015.htm

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).

Comment 1

[Jakob Kramer Hero]

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 - http://www.vojensbilleder.dk/byvandring1945.htm (measuring 1928 x 1550 pixels) - behaves correctly, whereas this map - http://www.vojensbilleder.dk/byvandring1950.htm (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: http://www.vojensbilleder.dk/byvandring_test.htm

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).

Comment 2

[roxleitan]

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.

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

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.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

This is a regression of bug 1442190 given regression range https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f807beef229718c015553bac09e4f638ca2add1&tochange=665843c6cfd1a3049128597afbef8a68bcc1e086

Comment 5

[Ryan VanderMeulen [:RyanVM]]

With any luck, it's the same root cause as bug 1471181.

Comment 6

[Maire Reavy [:mreavy]]

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!

Comment 7

[Miko Mynttinen]

This sounds like a clipping or invalidation issue. Will investigate more along with the bug 1471181.

Comment 8

[Miko Mynttinen]

Attachment: Bug 1472465 - Update flattened nsDisplayOpacity geometry despite empty invalidation region

Review commit: https://reviewboard.mozilla.org/r/257100/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/257100/

Comment 9

[Miko Mynttinen]

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 10

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8992221 [details]
Bug 1472465 - Update flattened nsDisplayOpacity geometry despite empty invalidation region

https://reviewboard.mozilla.org/r/257100/#review263900

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d72e5318d9cf
Update flattened nsDisplayOpacity geometry despite empty invalidation region r=mattwoodrow

Comment 12

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/d72e5318d9cf

Comment 14

[Miko Mynttinen]

I am assuming we want to uplift this due to bug 1471181?

Comment 15

[Ryan VanderMeulen [:RyanVM]]

That would be nice indeed, yes :)

Comment 16

[Miko Mynttinen]

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.

Comment 17

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/076e903341b4

Comment 19

[Anca Soncutean, Desktop QA]

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.