1236868 - Autocomplete popup causes xul:panel to hide

Status: RESOLVED WONTFIX

(DevTools :: Console, defect)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

This has been originally reported as PixelPerfect (devtools extension) issue here:
https://github.com/firebug/pixel-perfect/issues/72

STR:
I was able to replicate the issue with a new Firefox profile and after building the extension using this repository.

1) Install PixelPerfect extension
https://github.com/firebug/pixel-perfect/releases
2) Open Pixel Perfect xul:panel by clicking on PP Firefox toolbar button.
(sometimes the panel disappears now)
3) Click the 'pick an element' button or attempt to change styles in the Dev Tools DOM and Style Editor.
4) The Pixel Perfect panel hides.

---

Here is a stack I am seeing:

resource://gre/modules/commonjs/toolkit/loader.js -> resource://pixelperfectplugin-at-openhouseconcepts-dot-com/node_modules/firebug.sdk/lib/core/trace.js (159)
resource://gre/modules/commonjs/toolkit/loader.js -> resource://pixelperfectplugin-at-openhouseconcepts-dot-com/lib/pixel-perfect-popup.js (296)
chrome://global/content/bindings/popup.xml (134)
resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/shared/autocomplete-popup.js (90)
resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/styleinspector/rule-view.js (1382)
resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/styleinspector/style-inspector.js (31)
chrome://devtools/content/styleinspector/cssruleview.xhtml (27)
resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/client/framework/sidebar.js (244)


It looks like hiding the "devtools_autoCompletePopup" hides also the panel coming from PixelPerfect.

Any tips why this would happen?
Or is this known platform issue?

Honza

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

@bgrins: do you have any tips why this happens?

Honza

Comment 2

[Brian Grinstead [:bgrins]]

Does the pixel perfect popup have the 'noautohide' attribute set?  Because if I go to 'help -> firefox tour' (or open this tab: https://www.mozilla.org/en-US/firefox/46.0a1/tour/) then I can edit styles without that ui tour popup disappearing.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Brian Grinstead [:bgrins] from comment #2)
> Does the pixel perfect popup have the 'noautohide' attribute set?
Yes

I spent some more time on it today and it looks like the "popuphidden" listener wasn't properly registered.

@Matteo, the extension was using sdk/dom/events module to register "popuphidden" event for xul:panel, but the event handler was executed event by autocomplete-popup from devtools (see comment #0).

When I replaced:
DomEvents.on(this.panel, "popuphidden", this.onPopupHidden);
by:
this.panel.addEventListener("popuphidden", this.onPopupHidden);

... it seems to work properly now (but I am yet waiting for a feedback from the original reporter).

Here is my patch:
https://github.com/firebug/pixel-perfect/commit/b84da15a64b54c2084e812232fb767ae010d6019

Do you know about any reason why using the module from SDK would cause the problem?

Honza

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

Sorry for my late reply, Honza. It seems that the SDK behavior is changed; in the past `DomEvents.on` used to do exactly the same thing of `addEventListener`. Now, it uses ShimWaiver, that, I have to say, I've no idea what's is purpose, and why it's the default behavior. Gabor probably knows more about that, and why it behaves differently.

You can still use `DomEvents`, if you force to do not use ShimWaiver, so: `DomEvents.on(this.panel, "popuphidden", this.onPopupHidden, false, true);` but at this point you can just use `this.panel.addEventListener` IMVHO.

Comment 5

[Gabor Krizsanits (INACTIVE)]

(In reply to Matteo Ferretti [:matteo][:zer0] from comment #4)
> Sorry for my late reply, Honza. It seems that the SDK behavior is changed;
> in the past `DomEvents.on` used to do exactly the same thing of
> `addEventListener`. Now, it uses ShimWaiver, that, I have to say, I've no

That was before e10s. Now the content window lives in the child process. The
shim layer is simulating a direct access to the content window from the parent
process making DomEvents work, except it does it with CPOWs with unsafe sync
messages. The ShimWaiver waives this mechanism, we do this to prevent CPOW
usage from the SDK slowing down add-ons. Unfortunately that means that some
of the low level APIs are broken, and there is no current plan to fix that.
While high level APIs are a priority to work with e10s, and as much I can
tell they are working, low level APIs can be broken and don't think anyone
will have the time to work on them any time soon.

Comment 6

[Nicolas Chevobbe [:nchevobbe]]

it looks like the extension is no more available ?
Honza, do you think we can close this bug, or is the root problem here still an issue ?

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Yeah, this can be closed.
Honza