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

VERIFIED FIXED in Firefox 63

Status

()

defect
P3
normal
VERIFIED FIXED
Last year
10 months ago

People

(Reporter: mhryn, Assigned: mattwoodrow)

Tracking

({testcase})

Trunk
mozilla63
Points:
---

Firefox Tracking Flags

(firefox63 fixed)

Details

Attachments

(2 attachments)

Posted file 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
Actually, the problem surfaces regardless of the DPI settings - 90% page zoom is enough.
"
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).
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.
I get expected results with Firefox 61.0a1 buildID=20180423220120 for both tests.

WORKSFORME
Component: Untriaged → Layout
Keywords: testcase
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → All
Whiteboard: WFM
Version: 59 Branch → Trunk
@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
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.
Component: Layout → Layout: View Rendering
OS: Linux → All
Whiteboard: WFM
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
Cannot repro with WR fwiw. Maybe some coordinate space confusion somewhere?
Component: Layout: View Rendering → Layout: Web Painting
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Assignee: nobody → matt.woodrow
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.
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 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
Attachment #8986655 - Flags: review?(tnikkel) → review+
Pushed by mwoodrow@mozilla.com:
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
Backout by ebalazs@mozilla.com:
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
Pushed by mwoodrow@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/e7732e4cb0c9
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
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
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.