1923304 - www.icloud.com - The check icon for the to-do list inside the "Notes" section is broken

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10
Firefox version: Firefox 131.0

Steps to reproduce:

1. Navigate to: https://www.icloud.com and perform account login
2. Access the https://www.icloud.com/notes/ section
3. Write a note and select all the entries
4. Click on the "Make a checklist" option located at the top of the entries and observe

Expected Behavior:
Checklist bullets are added

Actual Behavior:
Black squares are added

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/142501

Comment 1

[Raul Bucata]

Attachment: 20241008_134731.mp4

Comment 2

[Sky Schubert [:skyschub]]

This is one gigantic <canvas>. :(

Comment 5

[Charles Dingman]

I am experiencing the same problem, as of November 4, 2024, with FireFox 132.0 on Windows 11 Pro 23H2 build 22631.4169. As noted in one of the duplicate bugs (1925781), another way to reproduce this problem is to create an Apple note on an iOS device using the checklist feature, check some items off and leave others unchecked, and then view it on iCloud.com in FireFox, where the expected checked or unchecked circles visible in the iOS notes app will instead appear in FireFox as opaque black boxes.

Comment 6

[Jason]

I am experiencing this same issue as of November 20, 2024 with Firefox 132.0.2 (64bit) running on Windows Pro (v. 23H2). Replicated issue via private browsing window with all extensions disabled.

Comment 7

[Jason]

Attachment: 2024-11-20_09-55-05.jpg

Bug view generated:
Firefox version 132.0.2 (64-bit)
Windows Pro (Version 23H2, Installed on ‎9/‎19/‎2023, OS build, 22631.4460, Windows Feature Experience Pack 1000.22700.1047.0).
Processor: 12th Gen Intel(R) Core(TM) i9-12900 2.40 GHz
Installed RAM: 64.0 GB (63.6 GB usable)
System type: 64-bit operating system, x64-based processor
Pen and touch: No pen or touch input is available for this display

Comment 8

[Bob Hood [:bhood]]

Kelsey, Nical thinks this involves WebGL canvas. Can you have a look when you get a chance?

Comment 9

[Narada B]

Any updates on this? still an issue.

Comment 10

[Kelsey Gilbert [:jgilbert]]

I can repro. I'll look at a canvas-rr recording of this.

Comment 11

[Monstera]

I am also experiencing this problem. In addition it seems that the lowercase letter x is rendered wrong too, but only in the "Body" font. It is displayed as an arrow pointing up right.

Comment 12

[Kelsey Gilbert [:jgilbert]]

I am narrowing down the issue still, but other work is competing for priority.

Comment 13

[Kelsey Gilbert [:jgilbert]]

Attachment: chrome recording (6).trim.json

Comment 15

[Kelsey Gilbert [:jgilbert]]

I tried userAgent spoofing and Firefox (pretending to be Chrome) didn't change, still broken in Firefox.

Comment 16

[Kelsey Gilbert [:jgilbert]]

Attachment: icloud-recording-6-vs-47.diff

A diff between a recording in Chrome (renders correctly in both browsers) and Firefox (renders incorrectly in both browsers).

Comment 17

[Kelsey Gilbert [:jgilbert]]

That diff inlined here, since it's short:

-// Chrome recording (6).json
+// Firefox recording(47).json
 ["$gl","bufferSubData",[34962,144,"=Float32Array:^AAAAAJrBwkEAAIA/AAAAAAAAAAAAAAAAAAAAAJrBwkEAAIA/msHCQQAAgD8AAAAA"]],
 ["$gl","createTexture",[],"$tex1"],
 ["$gl","bindTexture",[3553,"$tex1"]],
-["$gl","texImage2D",[3553,0,6408,150,150,0,6408,5121,null]],
+["$gl","texImage2D",[3553,0,6408,0,0,0,6408,5121,null]],
 ["$gl","texParameteri",[3553,10241,9729]],
 ["$gl","texParameteri",[3553,10240,9729]],
 ["$gl","texParameteri",[3553,10242,33071]],
 ["$gl","texParameteri",[3553,10243,33071]],
+["$gl","pixelStorei",[3317,4]],
+["$gl","texImage2D",[3553,0,6408,6408,5121,"@68"]],
 ["$gl","bufferSubData",[34962,192,"@0xa00560cd"]],
 ["$c2d.canvas","set width",[47]],
 ["$c2d.canvas","set height",[71]],
 ["$c2d","set textBaseline",["\"alphabetic"]],
 ["$c2d","set font",["\"17px ctSFUITextLight"]],
 ["$c2d","clearRect",[0,0,47,71]],
 ["$c2d","save",[]],
 ["$c2d","scale",[5,5]],
 ["$c2d","translate",[-1.0625,-3.43652]],
 ["$c2d","fillText",["\"b",0,16.1865]],
 ["$c2d","restore",[]],
 ["$c2d","getImageData",[0,0,47,71],"#ImageData"],
 ["$gl","bindTexture",[3553,"$tex2"]],
-["$gl","pixelStorei",[3317,1]],
-["$gl","texSubImage2D",[3553,0,142,128,47,71,6406,5121,"@0x13ad5fea"]],
+["$gl","texSubImage2D",[3553,0,142,128,47,71,6406,5121,"@0x111c3848"]],

Comment 18

[Kelsey Gilbert [:jgilbert]]

This looks like a buggy website.

Chrome seems to do a 2-phase alloc+upload of what is probably a 150x150 image, whereas Firefox allocates a 0x0 texture and doesn't upload anything to it:

-["$gl","texImage2D",[3553,0,6408,150,150,0,6408,5121,null]],
+["$gl","texImage2D",[3553,0,6408,0,0,0,6408,5121,null]],
 ["$gl","texParameteri",[3553,10241,9729]],
 ["$gl","texParameteri",[3553,10240,9729]],
 ["$gl","texParameteri",[3553,10242,33071]],
 ["$gl","texParameteri",[3553,10243,33071]],
+["$gl","pixelStorei",[3317,4]],
+["$gl","texImage2D",[3553,0,6408,6408,5121,"@68"]],

This two-pass allocation+setting is fine, though the latter should ideally be texSubImage2D instead of texImage2D.

In Firefox it tries to allocate 0x0 instead of 150x150, and while it calls texParameteri, the website doesn't even make the second call to texImage2D that actually sets the data. (also Chrome sets pixelStorei before upload, but reasonably doesn't bother in Firefox because it's not going to upload anything)

Comment 19

[Kelsey Gilbert [:jgilbert]]

Attachment: non-dom-svg-width-and-height.html

Firefox and Chrome have different behavior for img.width and img.height for SVGs when they are not attached to the DOM.

Firefox gives width: 0, height: 0
Chrome gives width: 150, height: 150

I suspect this is what drives the differences here.

Comment 20

[Emilio Cobos Álvarez [:emilio]]

That SVG doesn't have a width or height, just an aspect ratio from its viewBox:

<svg viewBox="-5 -5 104.6099853515625 104.6572265625" version="1.1" xmlns="http://www.w3.org/2000/svg"><g fill="rgba(235,184,0,1)" transform="matrix(1 0 0 1 -8.740039062500045 85.05859375)"><path d="M58.5449 14.5508C85.791 14.5508 108.35-8.05664 108.35-35.2539C108.35-62.5 85.7422-85.0586 58.4961-85.0586C31.2988-85.0586 8.74023-62.5 8.74023-35.2539C8.74023-8.05664 31.3477 14.5508 58.5449 14.5508ZM53.0762-11.377C51.416-11.377 50.0488-12.0605 48.7793-13.7695L36.5234-28.8086C35.791-29.7852 35.3516-30.8594 35.3516-31.9824C35.3516-34.1797 37.0605-35.9863 39.2578-35.9863C40.6738-35.9863 41.748-35.5469 42.9688-33.9355L52.8809-21.1426L73.7305-54.6387C74.6582-56.1035 75.9277-56.8848 77.1973-56.8848C79.3457-56.8848 81.3477-55.4199 81.3477-53.125C81.3477-52.0508 80.7129-50.9277 80.127-49.9023L57.1777-13.7695C56.1523-12.1582 54.7363-11.377 53.0762-11.377Z" /></g></svg>

So I think this is https://issues.chromium.org/issues/41357911?

Comment 21

[Kelsey Gilbert [:jgilbert]]

Injecting this intervention into the page causes it to work in Firefox again:

   if (true) {
      const proto = HTMLImageElement.prototype;
      const descs = Object.getOwnPropertyDescriptors(proto);
      const WAS = {};
      for (const k of ['width', 'height', 'naturalWidth', 'naturalHeight']) {
         const desc = descs[k];
         WAS[k] = desc.get;
      }
      for (const k of ['width', 'height', 'naturalWidth', 'naturalHeight']) {
         const desc = descs[k];
         desc.get = function() {
            let ret = WAS[k].call(this);
            if (!ret && this.src.startsWith('data:image/svg+xml')) {
               const nw = WAS.naturalWidth.call(this);
               const nh = WAS.naturalHeight.call(this);
               if (!nw && !nh) {
                  ret = 150;
                  console.log(this, `.${k} => 0 -> 150`);
               }
            }
            return ret;
         };
      }
      Object.defineProperties(proto, descs);
   }

If Chrome matches Firefox here, they should expect to regress on this page.

Comment 22

[Kelsey Gilbert [:jgilbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)

So I think this is https://issues.chromium.org/issues/41357911?

It looks like it, yes!

Comment 23

[Kelsey Gilbert [:jgilbert]]

Over to Layout then!

Comment 24

[Daniel Holbert [:dholbert]]

(In reply to Kelsey Gilbert [:jgilbert] from comment #23)

Over to Layout then!

Rather, let's call this a Site Report bug with a dependency on the bug that Emilio noted (which is really tracking a case where we're spec-compliant and other browsers have a bug that they're taking steps towards solving).

Thanks for diagnosing!

Comment 25

[Daniel Holbert [:dholbert]]

+cc karlcow -- hi karl! This seems to be a case where icloud.com is accidentally depending on a bug in Chromium/WebKit that you were recently looking at (and that Chromium folks are taking steps towards fixing) -- specifically, they're depending on getting a nonzero naturalWidth for a dimensionless SVG image, which is:
https://bugs.webkit.org/show_bug.cgi?id=284341
https://issues.chromium.org/issues/41357911

They're getting broken results in Firefox (and maybe soon Chrome and/or WebKit if those^ bugs are fixed) as a result.

Would you mind reporting this to the iCloud folks? They just need to either:

• add some nonzero width & height attributes to their "checkmark" SVG image here (on the <svg> element that's inside their base64-data-URI-encoded graphic, markup quoted in comment 20 and data-URI-encoding quoted in comment 19's attachment);
• ...or adjust their logic that checks the image's naturalWidth & naturalHeight to gracefully handle those returning 0.

Comment 26

[Karl Dubost💡 :karlcow]

Hi Daniel.
Thanks for the heads up.
This is tracked by rdar://143937552.

Comment 27

[Daniel Holbert [:dholbert]]

Like bug 1951871, this should be fixed in the latest Nightly due to bug 1965560 landing.

I can't test the iCloud website at the moment (I don't have my apple-account 2fa device handy) but I'll test it later on in Nightly to confirm that it's fixed.

Comment 28

[Daniel Holbert [:dholbert]]

OK, I was able to test and I confirmed this is fixed in Nightly 141.0a1 (2025-06-01) (64-bit)

Comment 29

[Daniel Holbert [:dholbert]]

--> Updating metadata to reflect that this affected Firefox on Android as well. I just tried there in latest Nightly on Android (which is a few days out of date due to regular play-store delays and hence doesn't have the fix yet), and I can reproduce there.

Comment 30

[Calin Tanase]

Verified, the issue is still reproducible on the RC build. @dholbert does this actually have the target milestone for 141?

Tested with:

• Browser / Version: Firefox 140.0-candidate build 1
• Operating System: Windows 10

Comment 31

[Daniel Holbert [:dholbert]]

This is expected to be fixed in 141, not 140.