852425 - Addon repacked with 1.14rc1 and opted in to pwpb throws immediately upon requiring panel module.

Status: RESOLVED INVALID

(Add-on SDK Graveyard :: General, defect)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I repacked my addon with SDK 1.14rc1 and added the permissions flag to package.json so my addon can run in private windows.
My addon requires the panel module. When I do cfx run against Firefox beta, it immediately throws a huge traceback, ending in: 
File "resource://jid0-qvxozn2i0qxem6fxf1foju0co7i-at-jetpack/addon-sdk/lib/sdk/panel.js", line 32, in
  throw Error('The panel module cannot be used with per-window private browsing at the moment, see Bug 816257');

This is before any content has loaded, and the only window open is not a private window.

None of the rest of my addon's code is able to run because of the thrown error.

My addon's code is hosted in the link in the URL field.

Pretty sure this blocks the release if others can reproduce this.

I'm on Windows, if that matters.

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Erik told me on twitter that this is expected, that we can't use panels at all if opting in to private windows.

I was under the impression that panels just wouldn't work in private windows, not that my entire addon will break by simply requiring panel and wanting to run in private windows.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

A much simpler testcase:
Activate SDK 1.14rc1.
cfx init someaddon
cd someaddon
Replace package.json and lib/main.js with the content from https://gist.github.com/KWierso/5193949
cfx run

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I see two distinct behaviours, depending on the version of Firefox:

Fx 20: total failure, add-on doesn't work
Fx 21 & 22: panels work fine in private windows if the add-on is opted in, but the add-on doesn't work at all if the opt-in flag isn't there.

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to Jeff Griffiths (:canuckistani) from comment #3)
> Fx 20: total failure, add-on doesn't work
I see this and can reproduce this...

> Fx 21 & 22: panels work fine in private windows if the add-on is opted in,
I see this and can reproduce this...

> but the add-on doesn't work at all if the opt-in flag isn't there.
But my addon seems to work fine if I remove the pb permissions flag, in Nightly and Aurora...

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

[23:36]	<erikvold>	has nightly been rebuilt with the uplift ?
[23:38]	<KWierso|Home>	erikvold: uplift was only pushed to try
	<erikvold>	and do we use internal modules by default now?
[23:40]	<KWierso|Home>	erikvold: :|


Oh yeah, Aurora and Nightly use the built-in, not-yet-updated modules... 

If I pass cfx run the -o (overload) flag, I get the same problems as I do on Beta.

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Wes Kocher (:KWierso) from comment #0)
> I repacked my addon with SDK 1.14rc1 and added the permissions flag to
> package.json so my addon can run in private windows.
> My addon requires the panel module. When I do cfx run against Firefox beta,
> it immediately throws a huge traceback, ending in: 
> File
> "resource://jid0-qvxozn2i0qxem6fxf1foju0co7i-at-jetpack/addon-sdk/lib/sdk/
> panel.js", line 32, in
>   throw Error('The panel module cannot be used with per-window private
> browsing at the moment, see Bug 816257');
> 
> This is before any content has loaded, and the only window open is not a
> private window.
> 
> None of the rest of my addon's code is able to run because of the thrown
> error.
> 
> My addon's code is hosted in the link in the URL field.
> 
> Pretty sure this blocks the release if others can reproduce this.
> 
> I'm on Windows, if that matters.

This is expected, because so many use cases trigger the panel via UI, it seemed odd to me to have that UI do nothing (console warning == nothing to a user imo), also this behavior could be difficult for a reviewer to spot.  Throwing an error during the add-on load is something that no reviewer would miss.

Comment 7

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

So it actually sounds like this is how it's supposed to work, and that most of the confusion was over the built-in modules not yet being updated to this experience.

Closing as invalid.