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. https://github.com/mozilla/firefox-ui-tests/blob/master/firefox_ui_tests/functional/security/test_dv_certificate.py#L43 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
It would be good if someone could attach a screenshot and a minified, reproducible test case to this bug.
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.
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?
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 https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#7196. 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.
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: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox#Debugging_popups
Yeah, that's half the answer I used in the end: https://github.com/mozilla/firefox-ui-tests/compare/mozilla-central...Pike:l10n-tests?expand=1#diff-5a5eb75c022ec5349e22d60f86f64d2aR425 has that. The other half is to use the popup as background for an in-browser element, which I did at https://github.com/mozilla/firefox-ui-tests/compare/mozilla-central...Pike:l10n-tests?expand=1#diff-7f5b4a1fb4d95301c4852903576731fcR73 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 https://searchfox.org/mozilla-central/rev/84cea84b12145d752e50ddca6be5462c38510e35/testing/marionette/server.js#60?
I wouldn't know the pros and cons of that, sorry. Also, I haven't touched anything marionette in a long time.
You need to log in before you can comment on or make changes to this bug.