1380109 - [oop webextensions] When moving a WebExtension to the panel, it closes the panel when clicked (doesn't open subview)

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P1)

Description

[Blake Winton (:bwinton) (:☕️)]

STR:
  Launch a new profile.
  Go to https://testpilot.firefox.com/experiments/snooze-tabs
  Click the button to install test pilot and enable snooze tabs.
  Click Add, then click Ok.
  Right-click the SnoozeTabs button, and move it to the overflow menu.
  Click the Overflow menu, then Snooze Tab until...

Unexpected result:
  The panel closes.  ;)

Extra, potentially helpful data:
  The code for the SnoozeTabs webextension is at https://github.com/bwinton/SnoozeTabs
  The popup is just a browserAction, as shown at https://github.com/bwinton/SnoozeTabs/blob/master/package.json#L92

Comment 1

[:Gijs (he/him)]

I can't actually reproduce with these steps. Do you see this on all OSes? Completely clean profile? Does it matter if I open the popup once before moving it to the overflow panel or something? (I tested on OS X, 56.0a1 (2017-07-11) (64-bit), several times because I was confused...)

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Windows 10 is all I have access to.  Completely clean profile.  I didn't open the popup before moving it.

Comment 3

[:Gijs (he/him)]

(In reply to Blake Winton (:bwinton) (:☕️) from comment #2)
> Windows 10 is all I have access to.  Completely clean profile.  I didn't
> open the popup before moving it.

Hm. I don't have access to Windows again until Monday, but can you check if this problem reproduces with a non-photon build in the (old) hamburger panel? Non-photon builds should be available from the cedar twig ( https://treeherder.mozilla.org/#/jobs?repo=cedar ). Alternatively, if you could check if there is a regression window for this in the last month or two - since bug 1354071 (maybe this broke with bug 1370967?) - that would be helpful.

Comment 4

[Blake Winton (:bwinton) (:☕️)]

Oh!  Fails in Cedar…
Mozregression blames https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=392ed89ec2730a48d10b1cec741e86a242d28aa3&tochange=a625a2e9b3333a8e76982ea65f077cfded6ac224 which is maybe not so helpful, but perhaps also not entirely surprising?  ;)
(I suspect it's the "Enable OOP extensions by default on Windows" part, but that's just a guess.)

Comment 5

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
Sounds like we're enabling this for 56, in which case we should make sure it gets fixed in that cycle.

(In reply to Blake Winton (:bwinton) (:☕️) from comment #4)
> Oh!  Fails in Cedar…
> Mozregression blames
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=392ed89ec2730a48d10b1cec741e86a242d28aa3&tochange=a625
> a2e9b3333a8e76982ea65f077cfded6ac224 which is maybe not so helpful, but
> perhaps also not entirely surprising?  ;)
> (I suspect it's the "Enable OOP extensions by default on Windows" part, but
> that's just a guess.)

Ah, that also matches up with me having similar-ish issues with oop webextension panel tests on osx on my local machine... (last comment in bug 1354086).

Comment 6

[Blake Winton (:bwinton) (:☕️)]

Also, if I toggle `extensions.webextensions.remote` to `false`, then the problem goes away, and the panel shows correctly.

Comment 7

[Gerry Chang [:gchang]]

Track 56+ as OOP extensions may be enabled in 56 by default.

Comment 8

[Andy McKay]

There might be a fix for this, Kris to check.

Comment 9

[Andy McKay]

This blocks 57 and not 56 because its only photon structure is enabled.

Comment 10

[:Gijs (he/him)]

(In reply to Andy McKay [:andym] from comment #9)
> This blocks 57 and not 56 because its only photon structure is enabled.

I don't think this correct. According to comment 4, this is also failing on cedar, the non-photon branch that reflects what beta 56 will work like.

Comment 11

[Kris Maglione [:kmag]]

(In reply to :Gijs from comment #10)
> (In reply to Andy McKay [:andym] from comment #9)
> > This blocks 57 and not 56 because its only photon structure is enabled.
> 
> I don't think this correct. According to comment 4, this is also failing on
> cedar, the non-photon branch that reflects what beta 56 will work like.

I haven't been able to reproduce this on m-c with photon structure disabled, so I don't think this is accurate.

Comment 12

[Kris Maglione [:kmag]]

Also, on a recent inbound, this seems to work with the Photon overflow panel, too.

Comment 13

[Andy McKay]

Sorry, I should have tested this yesterday when I had access to a Windows laptop. It works until I turn on remote on OS X, but there's a reason we haven't turned that on yet. Kris in comment 12 were you testing on a Windows build with oop on?

Comment 14

[Marcia Knous [:marcia]]

Triage team adding ni on :kmag to answer the question in Comment 13. Thanks.

Comment 15

[Vasilica Tamas, QA [:vtamas]]

Attachment: Animation.gif

This issue is no longer reproducible on Firefox 56.0a1 (2017-07-31) under Windows 10 64-bit with extensions.webextensions.remote = true and browser.photon.structure.enabled = true. See attached screencast.

Performed a regression with --find-fix flag and here are the results:
First good revision: 42ad059f07ba5057d4dc1b0fe00d96a0ece73bde
Last bad revision: b14c76c3291422c490576cd7e49b4a2b2bd95d8c
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b14c76c3291422c490576cd7e49b4a2b2bd95d8c&tochange=42ad059f07ba5057d4dc1b0fe00d96a0ece73bde

Blake, could you please confirm that this issue is also fixed on your end?

Comment 16

[Blake Winton (:bwinton) (:☕️)]

Yes, this is fixed on my end.  I believe we can resolve it.

Comment 17

[krupa raj [:krupa--use this to needinfo]]

Closing the bug based on comment 15 and comment 16.