Filing this bug to track the img.decode() API. Apparently Google Images uses it (or wants to) to swap seamlessly from the low-res to high-res image -- right now, that can trigger a flash (in Firefox at least) due to the high res image not being fully decoded when they swap it in. More info in https://twitter.com/jaffathecake/status/925702096300707842 . (See also bug 1416328 for the decoding attribute, which addresses similar use-cases more declaratively.) Spec link: https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode Chrome's intent-to-implement a while back (they've shipped it now, perhaps WebKit has as well, not sure): https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LMV9dBG_1-I GitHub issue where it was specced: https://github.com/whatwg/html/issues/2037
Also: there's a good overview of the difference between the use-cases for <img decoding="..."> attribute vs. the img.decode() API in this github comment: https://github.com/whatwg/html/issues/1920#issuecomment-256114499
I looked into what needed to be done on another bug around the time I implemented the attribute, but as I recall I just never got around to implementing it.
Assignee: nobody → aosmond
Severity: normal → enhancement
Priority: -- → P3
First implementation pass: try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2dfbf7f3637aa397f1160dcfe2824153280ce8e1 Looks like it wasn't put behind a secure context in WebKit: https://github.com/WebKit/webkit/commit/5dd19bfca6d603344914633e21db61b038032ea1#diff-5d3129a3412e339516f06e23f221ed36 Nor in Chrome: https://chromium.googlesource.com/chromium/src/+/a840c6a20c62e5ad20ec4e3419370173566b2850%5E%21/ https://chromium.googlesource.com/chromium/src/+/32a4a668e4e287c99a3917f1fc16e58a66215ef2%5E%21/
Still one test failing (locally) but most of the way there now: try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1ceedbd18674054ceee009fc296db9a3043aa64a
(In reply to Andrew Osmond [:aosmond] from comment #4) > Still one test failing (locally) but most of the way there now: > > try: > https://treeherder.mozilla.org/#/ > jobs?repo=try&revision=1ceedbd18674054ceee009fc296db9a3043aa64a The last failure is weird. The promise is indeed rejected, but it doesn't bubble up to the test framework.
(In reply to Andrew Osmond [:aosmond] from comment #5) > (In reply to Andrew Osmond [:aosmond] from comment #4) > > Still one test failing (locally) but most of the way there now: > > > > try: > > https://treeherder.mozilla.org/#/ > > jobs?repo=try&revision=1ceedbd18674054ceee009fc296db9a3043aa64a > > The last failure is weird. The promise is indeed rejected, but it doesn't > bubble up to the test framework. Spoke with arai on IRC about this, it looks like we kill the global object when the iframe is removed, so the promises are dropped on the floor, despite me issuing the rejection. I'll leave the test case failing for now.
The img decode API allows a web author to request that an image be decoded at its intrinsic size and be notified when it has been completed. This is useful to ensure an image is ready to display before adding it to the DOM tree -- this will help reduce flickering.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/5a7f8303d682 Implement img decode API. r=bzbarsky,tnikkel
You need to log in before you can comment on or make changes to this bug.