Closed Bug 1456111 Opened 2 years ago Closed 2 years ago

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


(Core :: Web Painting, defect, P3)




Tracking Status
firefox63 --- fixed


(Reporter: mhryn, Assigned: mattwoodrow)



(Keywords: testcase)


(2 files)

Attached 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


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

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

I will check with Firefox 61 now...

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


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.

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

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

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

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

Cannot repro with WR fwiw. Maybe some coordinate space confusion somewhere?
Component: Layout: View Rendering → Layout: Web Painting
This test

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.
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.
Attachment #8986655 - Flags: review?(tnikkel) → review+
Pushed by
Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel
Backout by
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
Make sure an empty pixel rectangle gets converted to an empty app unit rectangle, regardless of scale factor. r=tnikkel
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
When trying attachment 8970159 [details] and

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

Marking as VERIFIED
Flags: qe-verify+
Regressions: 1570363
You need to log in before you can comment on or make changes to this bug.