(In reply to Andrew Overholt [:overholt] from comment #7) > (In reply to :Gijs (he/him) from comment #2) > > The regression range and bugs listed as regressors actually suggests this is an imglib issue. Was there some other reason that made you move this out of imglib? > > I am curious about the above, too. If it's indeed an imagelib issue then I think we have our winner for who could work on it. > If it's not an imagelib issue (like I guess the data:// -> Blob suggestion), I'd ask Mike Conley but won't needinfo him here until we determine whether or not the root cause is in imagelib. I think the regressor is probably something along the line of bug 1135933, which isn't in imagelib - but before that set as desktop background wouldn't have worked in e10s at all. (In reply to Timothy Nikkel (:tnikkel) from comment #5) > (In reply to :Gijs (he/him) from comment #3) > > Never mind, looks like this is likely to have to do with the fact that the e10s implementation here uses a data URI at https://searchfox.org/mozilla-central/rev/250f5cc9fb8bdcbb6b23d2a06acfd48addb2f99b/browser/actors/ContextMenuChild.jsm#248, which fails for an image this large. > > > > I think we probably need to find some other way of passing this information to the parent... We can use a blob URI, but frankly, even painting this whole thing to a canvas to get a blob URI out of it seems dumb. Leaving ni to ask a different question: what better options have we got? > > Not really my area of expertise, but even just sending the compressed image source file would be better. I'm not aware of any IPC primitives that let us do this in the frontend JS / context menu code... are there some and am I just not aware of them, or would we need to invent a way to pass an image this way?
Bug 1579402 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Andrew Overholt [:overholt] from comment #7) > (In reply to :Gijs (he/him) from comment #2) > > The regression range and bugs listed as regressors actually suggests this is an imglib issue. Was there some other reason that made you move this out of imglib? > > I am curious about the above, too. If it's indeed an imagelib issue then I think we have our winner for who could work on it. > If it's not an imagelib issue (like I guess the data:// -> Blob suggestion), I'd ask Mike Conley but won't needinfo him here until we determine whether or not the root cause is in imagelib. I think the regressor is probably something along the line of bug 1135933, which isn't in imagelib - but before that set as desktop background wouldn't have worked in e10s at all - well, not since CPOWs broke / went away, if then. (In reply to Timothy Nikkel (:tnikkel) from comment #5) > (In reply to :Gijs (he/him) from comment #3) > > Never mind, looks like this is likely to have to do with the fact that the e10s implementation here uses a data URI at https://searchfox.org/mozilla-central/rev/250f5cc9fb8bdcbb6b23d2a06acfd48addb2f99b/browser/actors/ContextMenuChild.jsm#248, which fails for an image this large. > > > > I think we probably need to find some other way of passing this information to the parent... We can use a blob URI, but frankly, even painting this whole thing to a canvas to get a blob URI out of it seems dumb. Leaving ni to ask a different question: what better options have we got? > > Not really my area of expertise, but even just sending the compressed image source file would be better. I'm not aware of any IPC primitives that let us do this in the frontend JS / context menu code... are there some and am I just not aware of them, or would we need to invent a way to pass an image this way?