1307462 - [e10s] Cannot save image of <canvas> element

Status: VERIFIED DUPLICATE of bug 1307747

(Core :: IPC, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Although, I cannot provide the URL to reproduce this due to private web site. When I try to save image of <canvas> element (from context menu's "Save Image As...), I have see symptoms,

* Saved image is broken (cannot open by other applications)
* Crash as saving the image (e.g., https://crash-stats.mozilla.com/report/index/5ab6ca02-36dc-4b02-a2e0-825132161004)
* Failed to save image (not created the image file)

I cannot reproduce this in non-e10s window.

And regression range is:
https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=fbfe71842bb7a17bed00854803f59f67e58c0afd&full=1

It seems that this is a regression of bug 1294450.

jdm: do you have any ideas?

Comment 1

[Josh Matthews [:jdm]]

Do any of the symptoms get fixed by the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=1288997#c66 ?

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

No, I still reproduce this bug with the latest m-c which already included the patch.

I guess you know, but I'd like to explain what runs when you choose "Save Image As...". When it's executed on <canvas>, it tries to save the image as PNG file.  Then, it sends the png image as data URI to the parent process.  The data URI is a couple of MB when I do that. So, I guess bug 1294450 broke the code sending big data URI.

Comment 3

[Josh Matthews [:jdm]]

[Tracking Requested - why for this release]: Regression of working functionality.

Comment 4

[Josh Matthews [:jdm]]

Attachment: Testcase

Comment 5

[Josh Matthews [:jdm]]

This is broken even for the smallest canvases. The symptoms disappear when setting dom.ipc.processCount to >1, which means this was regressed by https://hg.mozilla.org/integration/mozilla-inbound/rev/44d130271ebc .

Comment 6

[Josh Matthews [:jdm]]

That being said, when I set processCount to 2 to workaround the issue, I can reproduce a second problem like described in comment 0: with a small canvas, the data is saved successfully. With a large canvas, the data is not.

Comment 7

[Josh Matthews [:jdm]]

Similarly, on tip of m-c that includes all patches from bug 1288997 and processCount set to 1, I see the same issues (but no more crashes, unlike nightly).

Comment 8

[Marcia Knous [:marcia]]

Tracking 52+ for this regression.

Comment 9

[Josh Matthews [:jdm]]

Bug 1294450 exposed this by using a SendStream actor instead of serializing a string stream for large data: URLs, but I think the problem is preexisting. We have this stack:

  * frame #0: 0x0000000112b175c8 XUL`mozilla::dom::BlobImplBase::BlobImplBase(this=0x000000012c4abda0, aContentType=0x00007fff4fd03a60, aLength=0) + 24 at File.h:392
    frame #1: 0x0000000112b6b54b XUL`mozilla::dom::EmptyBlobImpl::EmptyBlobImpl(this=0x000000012c4abda0, aContentType=0x00007fff4fd03a60) + 43 at File.h:771
    frame #2: 0x0000000112b5d6bd XUL`mozilla::dom::EmptyBlobImpl::EmptyBlobImpl(this=0x000000012c4abda0, aContentType=0x00007fff4fd03a60) + 29 at File.h:772
    frame #3: 0x0000000114e1cd03 XUL`mozilla::dom::(anonymous namespace)::CreateBlobImpl(aStream=0x00007fff4fd06928, aMetadata=0x00007fff4fd03a60)::CreateBlobImplMetadata const&) + 819 at Blob.cpp:748
    frame #4: 0x0000000114e1c5a5 XUL`mozilla::dom::(anonymous namespace)::CreateBlobImplFromBlobData(aBlobData=0x00007fff4fd06928, aMetadata=0x00007fff4fd03a60)::CreateBlobImplMetadata&) + 277 at Blob.cpp:775
    frame #5: 0x0000000114e1c400 XUL`mozilla::dom::(anonymous namespace)::CreateBlobImpl(aParams=0x00007fff4fd06910, aBlobData=0x00007fff4fd06928, aIsSameProcessActor=false) + 1072 at Blob.cpp:908
    frame #6: 0x0000000114e220f4 XUL`mozilla::dom::BlobParent* mozilla::dom::BlobParent::CreateFromParams<mozilla::dom::nsIContentParent>(aManager=0x000000013de3e8d0, aParams=0x00007fff4fd06910) + 532 at Blob.cpp:3994
    frame #7: 0x0000000114e1266d XUL`mozilla::dom::BlobParent::Create(aManager=0x000000013de3e8d0, aParams=0x00007fff4fd06910) + 125 at Blob.cpp:3845
    frame #8: 0x0000000114ebc280 XUL`mozilla::dom::nsIContentParent::AllocPBlobParent(this=0x000000013de3e8d0, aParams=0x00007fff4fd06910) + 48 at nsIContentParent.cpp:181
    frame #9: 0x0000000114e5c79f XUL`mozilla::dom::ContentParent::AllocPBlobParent(this=0x000000013de3e000, aParams=0x00007fff4fd06910) + 47 at ContentParent.cpp:3028
    frame #10: 0x0000000111b54feb XUL`mozilla::dom::PContentParent::OnMessageReceived(this=0x000000013de3e000, msg__=0x00007fff4fd06c08) + 5643 at PContentParent.cpp:3548

In CreateBlobImpl, we deserialize the provided input stream then call Available on it, and use the result to decide what kind of blob to create. Since we now have an nsPipeInputStream that returns 0 available bytes, we decide this is an empty blob and never read anything from the stream.

Comment 10

[Josh Matthews [:jdm]]

See previous explanation.

Comment 11

[Josh Matthews [:jdm]]

Attachment: Testcase #2

Comment 12

[Josh Matthews [:jdm]]

Forcing https://dxr.mozilla.org/mozilla-central/rev/ea104eeb14cc54da9a06c3766da63f73117723a0/dom/ipc/Blob.cpp#744 to be taken makes saving the canvas image work in testcase #2.

Comment 13

[Marco Castelluccio [:marco]]

(In reply to Josh Matthews [:jdm] from comment #5)
> This is broken even for the smallest canvases. The symptoms disappear when
> setting dom.ipc.processCount to >1, which means this was regressed by
> https://hg.mozilla.org/integration/mozilla-inbound/rev/44d130271ebc .

Is it still reproducible with https://hg.mozilla.org/mozilla-central/rev/18cb108e1c62?
It reverted that change.

Comment 14

[Andrea Marchesini [:baku]]

It seems a duplicate of bug 1307747.

Comment 16

[Marcia Knous [:marcia]]

Tracking 52- - we can track in the dupe.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Confirmed being fixed with another bug fix.

Comment 18

[Julien Cristau [:jcristau]]

updating status flag for 52