1167362 - "Save Image in Folder" add-on does not work with e10s

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[ivantyr]

Everything working except the option to save an image directly with a double-click

Comment 1

[Chris Peterson [:cpeterson]]

Achim, your "Save Image in Folder" add-on does not seem to be e10s compatible (multiprocess Firefox). If you have any questions about e10s, please drop by the #e10s IRC channel on irc.mozilla.org or check out the new MDN docs about e10s.

https://developer.mozilla.org/en-US/Add-ons/Working_with_multiprocess_Firefox

Comment 2

[Achim Seufert]

Hey Chris,
Hey ivantyr,

first of all... thank you guys for letting me know. Much appreciated!

I just took a few minutes to read the "Working with multiprocess Firefox"-article you mentioned above.
Wow! ... that's really deep stuff. :)

Well... I might not be the smartest guy out there; but I can imagine that many other (spare-time) addon-developers will have a hard time understandig all of this as well.
While I certainly did understand the basic concept behind all of this I didn't quite get an idea of how to "fix" this properly.
But I guess I'll have to invest more time and check the numerous code-examples.

However, my suggestion would be to prepare some basic examples that deal with the most common problems that occur with existing addons.
I remember that this was done in the past. And it really helped a lot!
Simply pointing out which code/call will break - and how it should be done instead.

From what I've read so far (and as far as I understand it at the moment), this part here is the only thing in my extension(s) that seem(s) to be problematic:

> internalSave(link, null, fname, null, null, false, null, acObject, null, gBrowser.contentDocument, false, null);

I guess the "gBrowser.contentDocument" is critical here.
Do I really have to create/register a seṕarate "frame script" which is communicating with the content-process in order to get the contentDocument... and then use the internalSave()-method?!

Any ideas? :)

Anyway... I will try to figure it out myself.

Thanks.

Achim

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Achim Seufert from comment #2)
> From what I've read so far (and as far as I understand it at the moment),
> this part here is the only thing in my extension(s) that seem(s) to be
> problematic:
> 
> > internalSave(link, null, fname, null, null, false, null, acObject, null, gBrowser.contentDocument, false, null);
> 
> I guess the "gBrowser.contentDocument" is critical here.
> Do I really have to create/register a seṕarate "frame script" which is
> communicating with the content-process in order to get the
> contentDocument... and then use the internalSave()-method?!

Jim, who can help Achim with his e10s question?

Comment 4

[Jim Mathies [:jimm]]

As a short term work round i think you can also use contentDocumentAsCPOW. Looks like we do that for a couple internal calls to internalSave.

Comment 5

[Achim Seufert]

Hi ivantyr,
Hi Chris,

I finally found the time to investigate the issue.

I just installed a nightly-build (42.0a1 (2015-07-18); Linux 64-bit) and tested the latest version of my extension (having E10S activated).
Everything works fine... also the double-click function.

Can you give me more detailed information on how to reproduce the problem you found?

Thanks in advance!

Achim

Comment 6

[ivantyr]

I've tried the function again using the 41.0a2-2015-07-19 and it's working now, though I am unsure which version I had at the time when it wasn't working