Closed Bug 1097530 Opened 10 years ago Closed 9 years ago

[e10s] Mega.nz Add-on's 'mega:' address doesn't work

Categories

(Firefox :: Extension Compatibility, defect)

x86_64
Windows
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
e10s + ---
firefox42 --- affected

People

(Reporter: suirtemedb, Unassigned)

References

()

Details

(Keywords: addon-compat)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141111030203

Steps to reproduce:

Installed the mega add-on from the mega website and attempted to navigate back to mega.co.nz


Actual results:

Gave a prompt that the address wasn't understood.


Expected results:

should have navigated to a mega 'chrome'
Blocks: e10s-addons
Status: UNCONFIRMED → NEW
Component: Untriaged → Extension Compatibility
Ever confirmed: true
Keywords: addon-compat
This bug is likely related to protocol handler bug 940206.
tracking-e10s: --- → +
Depends on: 940206
Blocks: 1189385
(In reply to Chris Peterson [:cpeterson] from comment #1)
> This bug is likely related to protocol handler bug 940206.

No, unfortunately it seems not to be the case.

This add-on registers a XPCOM component of its own as a nsIProtoclHandler implementation in bootstrap.js, i.e. in the parent process only.

To be fixed, it needs to register this component in the child process too (either moving all the XPCOM stuff in a process script, or duplicating the registration in its already existent frame script e10s), or maybe wait and see what happens in bug 1175056.
Depends on: 1175056
No longer depends on: 940206
CCing Guy Kloss because he seems to be the technical lead at Mega.

Since they already have a frame script ("e10s.js"), the easiest way to attempt a fix is refactoring the their mega: nsIProtocolHandler XPCOM implementation & registration code into a module, and importing it from both bootstrap.js and e10s.js.
Version: 36 Branch → Trunk
Our browser extension developer reported that the problem is fixed for the next version. As I was told the fix did not need any such refactoring, but I wouldn't know of the exact circumstances myself.
(In reply to gk from comment #4)
> Our browser extension developer reported that the problem is fixed for the
> next version. 

This seems to be fixed in 3.1.12, indeed. Thank you!

Since you already maintain a Chrome version, though, please start considering a migration to the WebExtensions API:

https://wiki.mozilla.org/WebExtensions
https://wiki.mozilla.org/WebExtensions/FAQ
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
OS: Windows 8.1 → Windows
QA Contact: Tobias.Besemer
Summary: [e10s] Mega Add-on's 'mega:' address doesn't work → [e10s] Mega.nz Add-on's 'mega:' address doesn't work
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: