1456111 - input[type="checkbox"] + label:after not repainted after unchecking the checkbox

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P3)

Description

[Maciej Hryniszak]

Attachment: index.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

Steps to reproduce:

1. Update system settings:
- On Windows, right-click on desktop, select "", in the dropdown "" select "150%"
- On Linux Mint XFCE go to All Settings, select Appearance, go to the "Fonts" tab, select "Custom DPI settings" and set it to 128
2. Open the enclosed index.html
3. Set page zoom to 90%
4. Click on all 3 items twice



Actual results:

Please note that the fat checkboxes to the right are still presented even though the actual underlying checkbox steering the display is already unchecked.


Expected results:

Both checkboxes (the real one and the artificial one constructed from rotated border) behave symmetrically.

Chrome and Edge behave properly regardless of the settings described in points 1 and 3 of the steps to reproduce

Comment 1

[Maciej Hryniszak]

Actually, the problem surfaces regardless of the DPI settings - 90% page zoom is enough.

Comment 2

[Gérard Talbot]

"
rotate() = rotate( [ <angle> | <zero> ] )

    specifies a 2D rotation by the angle specified in the parameter about the origin of the element, as defined by the transform-origin property. For example, rotate(90deg) would cause elements to appear rotated one-quarter of a turn in the clockwise direction.

scale() = scale( <number> [, <number> ]? )

    specifies a 2D scale operation by the [sx,sy] scaling vector described by the 2 parameters. If the second parameter is not provided, it takes a value equal to the first. For example, scale(1, 1) would leave an element unchanged, while scale(2, 2) would cause it to appear twice as long in both the X and Y axes, or four times its typical geometric size.
"
CSS Transforms Module Level 1, 
section 9.1 2D Transform Functions
https://www.w3.org/TR/css-transforms-1/#two-d-transform-functions

Macieij,

I get expected results with Firefox 52.7.3 ESR, under Linux Debian (stretch) 9.4 with KDE platform 5.8.6: the fat maroon check marks are present (or absent) if/when the real (black) check marks are present (or absent).

Comment 3

[Gérard Talbot]

Macieij,

I also get expected results with this 2-rules-and-10-declarations (more compact, streamlined and text size scalable) test:

http://www.gtalbot.org/BugzillaSection/Bug1456111-checked-checkbox-label-:afterGC.html

I will check with Firefox 61 now...

Also, you could use a real checkmark as your content attribute 

U+2713 ✓ CHECK MARK
U+2714 ✔ HEAVY CHECK MARK
https://en.wikipedia.org/wiki/Check_mark#Unicode

instead of an empty content attribute and your test would then be more compact and less dependent on borders, width, height, transform.

Comment 4

[Gérard Talbot]

I get expected results with Firefox 61.0a1 buildID=20180423220120 for both tests.

WORKSFORME

Comment 5

[Maciej Hryniszak]

@Gerard Talbot Please remember this bug occurs only below 100% page zoom (tested with 90%). I was able to reproduce the case on both Linux and Windows 10 with Firefox 59

Comment 6

[Gérard Talbot]

Macieij,

You are correct. I neglected this (zoom below 100%) when trying your test. 

When I try your test attachment 8970159 [details] with zoom = 90% (View > Zoom > Zoom Text Only checkbox must be unchecked), I get actual results. Interestingly, if I switch to another tab and then come back to your test tab, then I get expected results with Firefox 52.7.3. So, there is a high probability that there is - indeed - a bug here: a missing repaint call (hypothesis).

Your test could be optimized, furthermore reduced.

I will check again with a nightly build and then search for a duplicate.

Comment 7

[Gérard Talbot]

Macieij,

I am able to reproduce the actual results with this (2 rules, 7 declarations) reduced test:

http://www.gtalbot.org/BugzillaSection/Bug1456111-checked-checkbox-label-:afterGC-02.html

in Firefox 61.0a1 buildID=20180424100107 with zoom levels 90%, 110% and 120% . 

Chromium 64.0.3282.119 achieves expected results with all zoom levels.

I get expected results with Firefox 61 when switching to another tab and then switching back to the tab where the test is. So, this really looks like a repainting problem.


- - - - - - 


Firefox 61 passes

http://test.csswg.org/suites/css-transforms-1_dev/nightly-unstable/html/scale-zero-001.htm

and

http://test.csswg.org/suites/css-transforms-1_dev/nightly-unstable/html/scale-optional-second-001.htm

http://test.csswg.org/suites/css-transforms-1_dev/nightly-unstable/html/svg-scale-003.htm

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Cannot repro with WR fwiw. Maybe some coordinate space confusion somewhere?

Comment 9

[Gérard Talbot]

This test

http://www.gtalbot.org/BugzillaSection/Bug1456111-checked-checkbox-label-:afterGC-02.html

could be furthermore reduced: the test does not absolutely require both a <label> and an <input> checkbox.

I searched for a duplicate and did not find any.

Marking as NEW

- - - - - 

Emilio, please make sure you vary zoom level (and uncheck Zoom Text Only) and please provide os version, Firefox version and which test you are referring to.

Comment 10

[Matt Woodrow (:mattwoodrow)]

Attachment: Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor.

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

Comment 11

[Matt Woodrow (:mattwoodrow)]

ScaleRoundOut isn't super useful when the rect is (x,y,0,0) and x/y aren't pixel aligned, we end up computing a resulting rectangle with size 1x1.

Comment 12

[Matt Woodrow (:mattwoodrow)]

There's maybe a second bug here, that when we build an inactive layer and BuildLayer returns nullptr (like it was here, for a singular transform), then we don't invalidate for the pixels that it used to cover.

I don't think we can reasonably trigger that with the overflow rect calculations being correct though, and Miko is removing inactive layers, so not in a rush to fix it.

Comment 13

[Timothy Nikkel (:tnikkel)]

Comment on attachment 8986655 [details]
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor.

https://reviewboard.mozilla.org/r/251960/#review258398

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/97d67e0eaccf
Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel

Comment 15

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9d4c093a6ab
Backed out changeset 97d67e0eaccf for reftest failures e.g.: worker/workspace/build/tests/reftest/tests/layout/reftests/svg/image/image-x-01.svg on a CLOSED TREE

Comment 16

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8986655 [details]
Bug 1456111 - Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/251960/diff/1-2/

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e7732e4cb0c9
Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel

Comment 18

[Andreea Pavel [:apavel]]

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

Comment 19

[Gérard Talbot]

When trying attachment 8970159 [details] and 

http://www.gtalbot.org/BugzillaSection/Bug1456111-checked-checkbox-label-:afterGC-02.html

I get expected results with Firefox 63.0a1 buildID=20180710222524 .

Marking as VERIFIED