marionette.screenshot can't get hold of xul popup



3 years ago
6 months ago


(Reporter: Pike, Unassigned)


Firefox Tracking Flags

(Not tracked)




3 years ago
Getting a bug on file.

I'm working on a variant of the firefox-ui-tests, trying to get a screenshot of the security popup. is the line after which I'd like to go in and take a screenshot.

In various ways, the popup evades the screenshot.

Edwin mentioned that he saw a dev with a build that can do that. Henrik knows that this is a problem.

Given the importance of that pop-up in the 42 campaign, we have an opportunity to scale visual QA on the localizations of this UI if we could automate screenshots of it.

Filing, though filing late. Didn't realize the potential until now, sorry.
Edwin, can you remember who was that dev with the popup screenshot functionality? I would kinda love to get this bug fixed!

Given that this might be a Marionette issue, lets move it over to its component for now.
Component: XUL Widgets → Marionette
Product: Toolkit → Testing
Flags: needinfo?(edwong)
It would be good if someone could attach a screenshot and a minified, reproducible test case to this bug.

Comment 3

3 years ago
this is what Jared H. said: 
basically, you'd need to listen for whatever the "about to close" event is for whatever the panel subclass is that implements the doorhanger, then cancel the event (if it's cancelable) at least, that's how I implemented the pref for universal-search

maybe this is a feature request for a pref to do this without an add-on.
Flags: needinfo?(edwong)
Hm, Edwin this answer doesn't feel connected to the question in that bug. This is about a screenshot of popup elements and not something about canceling a close request for a popup. Maybe it was a different topic?

Comment 5

3 years ago
Actually, I think Edwin got the right pointer. My suspicion is that taking a screenshot messes with the focus, which it probably shouldn't. So that's one part of the bug, but I had no idea how to actually fix that.

But his pointer made me hunt, and I found

I'll try to mess with the noautohide attribute today :-)
Oh! You are right, then! It looks indeed promising. Lets hope that this idea will help. Thank you Axel for diving into that problem and Edwin for the pro tip.


3 years ago
Depends on: 1199183

Comment 7

3 years ago
To add why I filed bug 1199183:

I've added the noautohide to puppeteer, and then dug in, and screenshots still didn't work. But having the popup stay independent of focus allowed me to hook up a browser toolbox to the tested instance (how meta), and play around a bit. And changing the display: away from -moz-popup made the content show in the screenshot. Thus I filed a bug on layout.

Note, I also tried to use drawWidgetAsOnScreen, even that doesn't work, on my windows 7 VM. I.e. there it shows something, but not the popup. (on mac, it's just white, also, OK per comment in the IDL.)
I set the ui.popup.disable_autohide preference to true when writing tests for the door hanger notifications. It allows me to inspect the popups in browser toolbox without them disappearing. I found out about this feature here:

Comment 9

2 years ago
Yeah, that's half the answer I used in the end: has that.

The other half is to use the popup as background for an in-browser element, which I did at

Also in bug 1199183 comment 6.

Haven't actively looked into this in a while myself.
Is the right automation solution here to set ui.popup.disable_autohide as a recommended preference in
Flags: needinfo?(l10n)
Priority: -- → P5

Comment 11

6 months ago
I wouldn't know the pros and cons of that, sorry. Also, I haven't touched anything marionette in a long time.
Flags: needinfo?(l10n)
You need to log in before you can comment on or make changes to this bug.