Closed Bug 1189385 Opened 9 years ago Closed 9 years ago

[e10s] MEGA add-on compatibility tracker

Categories

(Firefox :: Extension Compatibility, defect)

42 Branch
All
Unspecified
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Tracking Status
e10s + ---
firefox40 --- ?
firefox41 --- ?
firefox42 --- affected
firefox43 --- ?

People

(Reporter: ma1, Assigned: gk)

References

()

Details

(Keywords: addon-compat)

Assignee: Giorgio Maone

Link to add-on: https://mega.nz/#firefox ( https://addons.mozilla.org/en-us/firefox/addon/meganz/ )

Contact info for add-on: https://mega.nz/

Add-on ID: {dc572301-7619-498c-a57d-39143191b318}

How well does it work?: 90% (or 0%, if you consider that you can't open its UI with "regular" means)

Steps to reproduce working features:
* Open chrome://mega/content/secure.html#fm/shares from the navigation bar and play with the download manager / sharing / chat UI

Steps to reproduce broken features: try to open any link generated by the add-on or other MEGA apps, or just the download link for the extension itself, https://mega.nz/#firefox - bug 1097530 will be triggered, making the add-on practically unusable

Any obvious performance problems? no

Chromium version: yes

Notes: it seems well maintained, bootstrapped and including e10s-specific code. Looks like just fixing bug 1097530 (i.e. bug 940206, most likely) should make it good until bootstrapped add-ons deprecation.
Summary: [e10s] Tab Mix Plus add-on compatibility tracker → [e10s] MEGA add-on compatibility tracker
=== ERRATA CORRIGE ===

Add-on ID: firefox@mega.co.nz
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Sorry, wrong tab!
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
CCing Guy Kloss because he seems to be the technical lead at Mega.

Guy Kloss, since you already maintain a Chrome version, though, please start considering a migration to the WebExtensions API:
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
https://wiki.mozilla.org/WebExtensions
https://wiki.mozilla.org/WebExtensions/FAQ
https://developer.mozilla.org/en-US/Add-ons/WebExtensions
Assignee: nobody → gk
tracking-e10s: --- → ?
Keywords: addon-compat
QA Contact: Tobias.Besemer
Hardware: Unspecified → All
Version: Trunk → 42 Branch
Chris Peterson do you manage http://arewee10syet.com/ ?

Because of you comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1046053#c2
Flags: needinfo?(cpeterson)
hi Tobias, I manage the arewee10syet.com site. What is your question? Should the site's entry for the MEGA add-on point to this bug instead of bug 1046053?
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson [:cpeterson] from comment #6)
> hi Tobias, I manage the arewee10syet.com site. What is your question? Should
> the site's entry for the MEGA add-on point to this bug instead of bug
> 1046053?

Yes, bug 1046053 is fixed, Giorgio Maone created this meta bug ...
... sub bug 1205802 is open.
Think this bug should be in arewee10syet.com for the Mega Extension.
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #7)
> Think this bug should be in arewee10syet.com for the Mega Extension.

Good idea. I updated the website to use this meta bug. When this bug's dependent bugs are fixed, we can resolved this meta bug and then the website will automatically make Mega green. :)
I think bug 1205802 should be marked as _INVALID_ since it has nothing to do with e10s, as for this meta-bug and since bug 1097530 is now fixed, this should now be marked as fixed as well?
(In reply to Diego Casorran [:diegocr] from comment #9)
> I think bug 1205802 should be marked as _INVALID_ since it has nothing to do
> with e10s, as for this meta-bug and since bug 1097530 is now fixed, this
> should now be marked as fixed as well?

Diego,

I have answered you in bug 1205802.
If you be the dev of the extensions and you can promise me, that bug 1205802 isn't related to e10s, I will remove it from "Depends on" again and mark this meta bug as fixed.
Bug 1205802 itself can (after updating the infos to it) stay open, until this bug is fixed. (Wherever this will be: By Mega or FF.) In bmo exist much more bugs that should be fixed not on the FF side, just to have them noted and to track them here, too. ;-)

Greets, Tobias.
Hi Tobias,

Well, the site loads fine through the extension over an e10s window (it's just that megasync feature what wasn't working), therefore the issue is in fact unrelated to e10s :-)

Cheers.
OK, mark this bug as "RESOLVED/FIXED".

(Extension works good for me, too.)

(In reply to Chris Peterson [:cpeterson] from comment #8)
> (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #7)
> > Think this bug should be in arewee10syet.com for the Mega Extension.
> 
> Good idea. I updated the website to use this meta bug. When this bug's
> dependent bugs are fixed, we can resolved this meta bug and then the website
> will automatically make Mega green. :)

Think it should go now to green ... :-)
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
No longer depends on: 1205802
Resolution: --- → FIXED
(In reply to Chris Peterson [:cpeterson] from comment #8)
> (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #7)
> > Think this bug should be in arewee10syet.com for the Mega Extension.
> Good idea. I updated the website to use this meta bug. When this bug's
> dependent bugs are fixed, we can resolved this meta bug and then the website
> will automatically make Mega green. :)

Chris, can you set the MEGA Extension on arewee10syet.com to "compatible" and make it green?
Flags: needinfo?(cpeterson)
The arewee10syet.com page should automatically show the correct status color when an extension's bug is fixed. (The page uses the Bugzilla API to check the bug status in real time.) However, it looks like the MEGA extension is still yellow because it is marked as a "shimmed" extension.

@ Bill: how do I know if an extension should be marked "shimmed" or "compatible"?
Flags: needinfo?(cpeterson) → needinfo?(wmccloskey)
Chris, shimmed data is coming from shim/CPOW telemetry analysis. If the data shows evidence the an add-on is shimmed, and the bugged isn't bugged, then arewee10syet will show it as yellow/shimmed.

I update the supporting spreadsheet once a month or so. But if this add-on is no longer using shims, it can be changed by hand.
Flags: needinfo?(wmccloskey)
(In reply to [:tracy] Tracy Walker - QA Mentor from comment #15)
> But if this add-on
> is no longer using shims, it can be changed by hand.

That's the problem. I don't know if this add-on is (still) using shims or not. :) So that is something the shim/CPOW telemetry will report?
(In reply to Chris Peterson [:cpeterson] from comment #16)
> (In reply to [:tracy] Tracy Walker - QA Mentor from comment #15)
> > But if this add-on
> > is no longer using shims, it can be changed by hand.
> 
> That's the problem. I don't know if this add-on is (still) using shims or
> not. :) So that is something the shim/CPOW telemetry will report?

Diego, can you solve this enigma for us about the MEGA Extension, that Chris can set at least this extension to "compatible" and green?

Chris & Tracy, thanks for your help! :-)

Btw. Diego: Now any future plans for WebExtension ??? ;-)
Flags: needinfo?(dcasorran)
Diego, here are the requested features for WebExtension v1.0:
https://bugzilla.mozilla.org/show_bug.cgi?id=1214433
Hi there,

The main purpose/logic behind the bootstrap.js file is redirecting https://mega.nz/ requests to the build-in app (either chrome://mega/content/secure.html or through the mega: protocol handler, whose channel resolves to the same chrome uri)

This is achieved using a nsIContentPolicy on Firefox Desktop, and nsIWebProgressListener on Firefox for Android.

However, for newer Firefox versions we're already using frame-scripts and nsIMessageListenerManager.

Hence, i suspect that CPOW telemetry is detecting the former interfaces usage, which weren't removed for compatibility with older Firefox versions.


> Btw. Diego: Now any future plans for WebExtension ??? ;-)

I'll be closely watching the progress of native.js

As long OS.File is fully supported, things will go on the right path here. Be sure we'll adopt to WE as soon it supports everything our current Firefox extension does.

Thanks for pointing out bug 1214433, i'll take a look at it next.
Flags: needinfo?(dcasorran)
(In reply to Diego Casorran [:diegocr] from comment #19)
> The main purpose/logic behind the bootstrap.js file is redirecting
> https://mega.nz/ requests to the build-in app (either
> chrome://mega/content/secure.html or through the mega: protocol handler,
> whose channel resolves to the same chrome uri)
> 
> This is achieved using a nsIContentPolicy on Firefox Desktop, and
> nsIWebProgressListener on Firefox for Android.
> 
> However, for newer Firefox versions we're already using frame-scripts and
> nsIMessageListenerManager.
> 
> I'll be closely watching the progress of native.js
> 
> As long OS.File is fully supported, things will go on the right path here.
> Be sure we'll adopt to WE as soon it supports everything our current Firefox
> extension does.

https://bugzilla.mozilla.org/show_bug.cgi?id=1097530#c5
(In reply to Giorgio Maone from comment #5)
> 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

Giorgio, does the answer from Diego to there requirements for WebExtension helps anyhow in the planing of v1.0?
Status: RESOLVED → VERIFIED
Flags: needinfo?(g.maone)
(In reply to Chris Peterson [:cpeterson] from comment #16)
> (In reply to [:tracy] Tracy Walker - QA Mentor from comment #15)
> > But if this add-on
> > is no longer using shims, it can be changed by hand.
> 
> That's the problem. I don't know if this add-on is (still) using shims or
> not. :) So that is something the shim/CPOW telemetry will report?

(In reply to Diego Casorran [:diegocr] from comment #19)
> Hence, i suspect that CPOW telemetry is detecting the former interfaces
> usage, which weren't removed for compatibility with older Firefox versions.

Chris, does this answer you question?
Flags: needinfo?(cpeterson)
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #21)
> Chris, does this answer you question?

Yes, thanks. I manually updated the add-on spreadsheet. The MEGA add-on is now green on arewee10syet.com. \o/
Flags: needinfo?(cpeterson)
(In reply to Chris Peterson [:cpeterson] from comment #22)
> (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #21)
> > Chris, does this answer you question?
> 
> Yes, thanks. I manually updated the add-on spreadsheet. The MEGA add-on is
> now green on arewee10syet.com. \o/

Great! :-)
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #20)
> 
> Giorgio, does the answer from Diego to there requirements for WebExtension
> helps anyhow in the planing of v1.0?

Yes: we did discuss his input in latest WebExtensions planning meeting, and we took note of the need of file system access functionality.

Implementing such a feature as Chromium-incompatible WebExtension API addition is probably a mid-term goal, but since bug 1199718 (native.js prototype) is already blocking webextensions1.0 they'll most likely be able to use OS.File directly from native.js.

I've filed bug 1219940 to track the porting requirements and process.
(In reply to Giorgio Maone from comment #24)
> (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #20)
> > 
> > Giorgio, does the answer from Diego to there requirements for WebExtension
> > helps anyhow in the planing of v1.0?
> 
> Yes: we did discuss his input in latest WebExtensions planning meeting, and
> we took note of the need of file system access functionality.

Thank you very much! :-)
Flags: needinfo?(g.maone)
Firefox 52.0.2
The "Add-on Compatibility Reporter" and "about:support" says "Multiprocess is NOT enabled" when I enable the MEGA add-on (v3.8.6): http://i.imgur.com/vAsawML.png
You need to log in before you can comment on or make changes to this bug.