createImageBitmap() and OffscreenCanvas drawImage() dows not work on Firefox 118
Categories
(Core :: Graphics: Canvas2D, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox-esr115 | --- | fixed |
| firefox117 | --- | wontfix |
| firefox118 | --- | wontfix |
| firefox119 | --- | fixed |
People
(Reporter: tkuri2010+bug, Assigned: aosmond)
References
Details
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-esr115+
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0
Steps to reproduce:
- crop an image: const newImage = createBitmapImage(oldImage, x, y, w, h)
- create a new OffscreenCanvas(w, h)
- drawImage(newImage, 0, 0) against to its 2d context
- convertToBlob() and save it as a file.
I wrote this codepen: https://codepen.io/tkuri2010/pen/bGOqojL
Actual results:
I got a blank image file.
Expected results:
I want to get a cropped image file.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Might be same issue as bug 1851943.
| Assignee | ||
Comment 3•2 years ago
|
||
These are not related. This bug has existed since OffscreenCanvas landed as far as I can tell.
| Assignee | ||
Comment 4•2 years ago
|
||
It appears that if we create an ImageBitmap, draw it to a canvas and draw it again to an OffscreenCanvas, then it only draws successfully into the first canvas.
| Assignee | ||
Comment 5•2 years ago
•
|
||
This is happening because the first canvas is a D2D canvas, and the OffscreenCanvas is a Skia canvas. When we crop the underlying source surface with the D2D canvas, we end up getting a SourceSurfaceRecording out of it, without a link to the original surface:
https://searchfox.org/mozilla-central/rev/09f7e00da9eaef55c80620c17e8575ddd4532451/dom/canvas/ImageBitmap.cpp#810
https://searchfox.org/mozilla-central/rev/09f7e00da9eaef55c80620c17e8575ddd4532451/dom/canvas/ImageBitmap.cpp#817
Which the Skia canvas cannot draw.
If we don't crop, we hit the OptimizeSourceSurface path, which for a DrawTargetRecording means it creates a SourceSurfaceRecording with a link to the original surface which we can use to draw with Skia:
https://searchfox.org/mozilla-central/rev/09f7e00da9eaef55c80620c17e8575ddd4532451/dom/canvas/ImageBitmap.cpp#870
https://searchfox.org/mozilla-central/rev/09f7e00da9eaef55c80620c17e8575ddd4532451/gfx/2d/DrawTargetRecording.cpp#601
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 6•2 years ago
|
||
When ImageBitmap::PrepareForDrawTarget is called, we must ensure
that the surface returned is acceptable to the given DrawTarget. If
it is not, then we need to recreate the surface from mData. We must
also ensure similar when we are creating a new ImageBitmap from
another ImageBitmap, as we don't know in what context it may be
used.
Additionally, we now no longer clear mPictureRect when we set
mSurface with the cached, cropped data. Since we may need to clear
the cached surface, we need to know the original crop rect.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 8•2 years ago
|
||
I'm going to wontfix this for beta because we've lived with this for a while. The patch could have been simpler but there were a number of similar/related bugs to the surface management I wanted to fix at the same time that would be hard to track. Better for this to ride the trains and consider an uplift to 115 ESR once we make it out to release.
Comment 9•2 years ago
|
||
| bugherder | ||
Comment 10•2 years ago
|
||
Is this ready for an esr115 approval request? Please nominate if so.
| Assignee | ||
Comment 11•1 year ago
|
||
Comment on attachment 9352802 [details]
Bug 1852420 - Ensure surface and crop rect used in ImageBitmap are valid.
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes canvas rendering bugs on Windows
- User impact if declined: Broken canvas depending on usage
- Fix Landed on Version: 119
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): No known regressions, been exercised in release for quite some time, changes are fairly localized.
Comment 12•1 year ago
|
||
Comment on attachment 9352802 [details]
Bug 1852420 - Ensure surface and crop rect used in ImageBitmap are valid.
Approved for 115.7esr.
Comment 13•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Description
•