updating Simulator with PB hotfix

22 views
Skip to first unread message

Myk Melez

unread,
Mar 26, 2013, 7:16:25 PM3/26/13
to mozilla-la...@googlegroups.com, amo-e...@mozilla.org
Rocketeers and AMO Editors!

The stable release of the Simulator is based on SDK 1.12. It no longer works on Nightly builds of Firefox because of the private browsing change, although it does still work on Aurora, Beta, and Release builds. Next week, after the trains jump their various tracks, it'll work only on Beta and Release builds.

Simulator engineers are working on the next version of the Simulator, which is based on SDK 1.14 and works with Firefox builds from all four channels. But it won't be ready by next week. So I'm considering hotfixing the stable release. What would be the best way to do this?

My inclination is to apply the minimal fix to the installation of SDK 1.12 with which we build the updated packages. That'd make one or more SDK files appear modified to the AMO Validator, but presumably the changes would be minimal and easy to review.

Another option is to rebuild the stable release of the Simulator against a newer version of the SDK, either 1.13 (if it includes the PB fix) or 1.14. But that seems riskier to do and more time-consuming to verify, for both the Simulator engineer who makes the change and the AMO editor who reviews the updated packages, because it results in significant changes to the SDK code and may also necessitate changes to the addon code (especially if we update to SDK 1.14, for which I think we needed to make some changes to the addon).

A third option is to simply tell Nightly/Aurora users to use the unstable preview builds hosted on ftp.mozilla.org. But a notice like that would be easy to miss, and I expect users would continue to install the stable release and not understand why it doesn't work.

Is there a better option I'm missing or a reason to prefer rebuilding against a newer version of the SDK? And if not, then what's the minimal fix to SDK 1.12 that solves the problem?

-myk

Jorge Villalobos

unread,
Mar 27, 2013, 9:12:56 AM3/27/13
to Myk Melez, mozilla-la...@googlegroups.com, amo-e...@mozilla.org, Kris Maglione
In what way will the add-on break on Nightly? Looking at your usage stats, about 4% of your users (about 2K) are using Aurora and Nightly, and it'll take a while after merge day for most of them to upgrade to the next major versions. It seems like a lot of effort to patch this if it won't take too long to properly repack to 1.14, unless the breakage is significant. Giving them the option to use the preview builds would also help mitigate any problems.

My 2 cents.

Jorge

Alexandre poirot

unread,
Mar 27, 2013, 12:04:35 PM3/27/13
to mozilla-la...@googlegroups.com, Myk Melez, amo-e...@mozilla.org, Kris Maglione, erik...@gmail.com
I had to explain by myself to someone in paris office, why the simulator wasn't working whereas it was succesfully installed in addon manager... Even if percentages are low, I'd really like to avoid unecessary loss of time for simulator users.

Hotfixing 1.12 sounds like a viable cheap option.
The precise revision fixing that exception is the following:
  https://github.com/mozilla/addon-sdk/commit/92573eada44e61eed590e535fc9aeaee63e059d9
Unfortunately, it was included in a big pull request:
  https://github.com/mozilla/addon-sdk/pull/718
And complex patch history makes it pull various dependencies and fails to apply.

Here is a simplier hotfix dedicated to 1.12 branch:
  https://github.com/ochameau/addon-sdk/commit/0cc58dc4158a75eb6eaf461edcab2f8c6062c408

Erik, Do you think that's reasonable action regarding private browsing?
The simulator doesn't seem to use private-browsing but just fails because of xpcom removal.



2013/3/27 Jorge Villalobos <jo...@mozilla.com>

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mozilla-labs-jet...@googlegroups.com.
To post to this group, send email to mozilla-la...@googlegroups.com.
Visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Myk Melez

unread,
Mar 27, 2013, 1:19:06 PM3/27/13
to Jorge Villalobos, mozilla-la...@googlegroups.com, amo-e...@mozilla.org, Kris Maglione
On 2013/03/27 06:12, Jorge Villalobos wrote:
In what way will the add-on break on Nightly?
The addon fails on startup because an SDK module tries to access a private-browsing API that no longer exists, triggering an exception.

Which means the addon doesn't work at all: no "Firefox OS Simulator" item appears in the Web Developer menu, and one cannot use addon functionality from the Dashboard even if one figures out how to access it some other way.


Looking at your usage stats, about 4% of your users (about 2K) are using Aurora and Nightly, and it'll take a while after merge day for most of them to upgrade to the next major versions.
I'm getting regular feedback from users complaining about this problem. It may be that only 4% of ADIs are reporting those Firefox versions, while a larger percentage of actual users are on them.


It seems like a lot of effort to patch this if it won't take too long to properly repack to 1.14, unless the breakage is significant.
I don't know how significant the breakage is, but a patch seems like a lot less effort to me, at least when it comes to testing the addon after patching the SDK to make sure it still works correctly, since it limits the extent of SDK changes to the absolute minimum required, whereas updating the SDK from 1.12 to 1.14 introduces a tremendous volume of SDK changes (two whole development cycles' worth!).


Giving them the option to use the preview builds would also help mitigate any problems.
Yes! Upon further reflection, this seems like a good idea regardless of what we do with the stable release. I have added a note to the addon's details, including direct links to the latest preview builds, which work, although AMO tells me to " Please use caution when installing third-party add-ons. If you are immediately prompted to install an add-on, please let us know."

Perhaps I should link to a page that then directs users to install the preview builds, i.e. make it a two-click process?

-myk

Erik Vold

unread,
Mar 27, 2013, 4:00:27 PM3/27/13
to mozilla-la...@googlegroups.com


On 2013-03-27, at 10:19, Myk Melez <m...@mozilla.org> wrote:

> On 2013/03/27 06:12, Jorge Villalobos wrote:
>> In what way will the add-on break on Nightly?
> The addon fails on startup because an SDK module tries to access a private-browsing API that no longer exists, triggering an exception.
>
> Which means the addon doesn't work at all: no "Firefox OS Simulator" item appears in the Web Developer menu, and one cannot use addon functionality from the Dashboard even if one figures out how to access it some other way.

the Simulator must be using the private-browsing module from 1.12 which means it isn't handling pwpb on beta on up correctly I assume. So I'd suggest releasing a version with 1.13 or higher or removing the usage of the private-browsing module (why is it used?)

Erik

Wes Kocher

unread,
Mar 27, 2013, 4:07:03 PM3/27/13
to mozilla-la...@googlegroups.com
On Wed, Mar 27, 2013 at 1:00 PM, Erik Vold <erik...@gmail.com> wrote:
> removing the usage of the private-browsing module (why is it used?)
Core SDK modules in 1.12 and earlier use the now-defunct
private-browsing module to see if the current session is in private
browsing mode, which breaks the addon entirely when the dummy private
browsing service that was added in 20 and removed in 22 is no longer
present. This dependency was removed in SDK 1.13, so repacking to 1.13
should avoid the problem.

Myk Melez

unread,
Mar 27, 2013, 4:10:14 PM3/27/13
to mozilla-la...@googlegroups.com, Wes Kocher, Erik Vold, Alexandre Poirot
On 2013/03/27 13:07, Wes Kocher wrote:
> On Wed, Mar 27, 2013 at 1:00 PM, Erik Vold <erik...@gmail.com> wrote:
>> removing the usage of the private-browsing module (why is it used?)
> Core SDK modules in 1.12 and earlier use the now-defunct
> private-browsing module to see if the current session is in private
> browsing mode, which breaks the addon entirely when the dummy private
> browsing service that was added in 20 and removed in 22 is no longer
> present.
Right! The addon doesn't use that module itself, but it uses other
modules that use it.

> This dependency was removed in SDK 1.13, so repacking to 1.13
> should avoid the problem.
Thanks, good to know! Although patching 1.12 still looks like the better
path, especially now that Alex has provided a patch to do so, given that
the change is much smaller.

-myk

Reply all
Reply to author
Forward
0 new messages