Closed Bug 1569135 Opened 4 months ago Closed 3 months ago

--screenshot option in Firefox headless mode stopped working

Categories

(Firefox :: Headless, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- fixed
firefox68 --- unaffected
firefox69 --- verified
firefox70 --- verified

People

(Reporter: pascalc, Assigned: aswan)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(2 files)

Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190725215157

STR:
1/ type firefox --screenshot https://mozilla.org in a terminal

ER:
A screenshot.png page is generated in the current folder

AR:
No screenshot generated.

This regression was reported by a user (guillermo) in IRC and I can reproduce the bug.

I quickly tested manually as I can't find how to use mozregression in headless mode, 68 is not affected but this is a 69 regression. marking as tracking for 69 and 70 as this is a functional regression of the headless mode.

Component: Untriaged → Headless

mozregression --good 2019-05-25 --arg="--screenshot" --arg="https://mozilla.org" --arg="--headless"
16:34.99 INFO: Last good revision: d08d899e5431458f7c28ca66a13e3e95dff9c7c1
16:34.99 INFO: First bad revision: 2236a18eb0a91be02e72c22e370a6f5aa877f11e
16:34.99 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d08d899e5431458f7c28ca66a13e3e95dff9c7c1&tochange=2236a18eb0a91be02e72c22e370a6f5aa877f11e

Regressed by bug 1560178 which was uplifted to beta, Gijs could you have a look please? Thanks!

Flags: needinfo?(gijskruitbosch+bugs)
Regressed by: 1560178

Andrew, can you maybe take a look at this since Gijs is on PTO for the next couple weeks and we're running low on time for Fx69? Thanks!

Flags: needinfo?(aswan)

It looks like --screenshot has always loaded the page to take a screenshot of in the parent process (the relevant code is basically the entire contents of browser/components/shell/HeadlessShell.jsm) so its no surprise that it was broken by bug 1560178.
My knowledge of the platform level here is shaky, the only way I would know how to approach this is to load a small document that contains a <browser remote="true"> and then load the actual content page inside that browser.
Leaving the needinfo for myself pending further research.

Flags: needinfo?(gijskruitbosch+bugs)

Okay, I think the approach from comment 4 is the only way to go.

Also this has a test but for some reason it is a chrome mochitest. The test copies the test profile preferences to create a profile to run firefox -screenshot but since this is a chrome mochitest, the new profile inherits among other things: browser.tabs.remote.autostart = false. So, we're testing the unsupported e10s-disabled configuration where of course content loads in the parent process are allowed. Yay.

Assignee: nobody → aswan
Flags: needinfo?(aswan)
See Also: → 1570554

not ready for landing, putting this up to get feedback before polishing.
note that the automated test of this feature is still broken, bug 1570554
is on file for fixing it.

Clearing the regression-window-wanted tag based on comment 2.

Thanks for looking at this, Andrew!

Summary: --screnshot option in Firefox headless mode stopped working → --screenshot option in Firefox headless mode stopped working
Attachment #9082157 - Attachment description: Bug 1569135 first pass r=kmag → Bug 1569135 Fix --screenshot r=kmag
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70

Comment on attachment 9082157 [details]
Bug 1569135 Fix --screenshot r=kmag

Beta/Release Uplift Approval Request

  • User impact if declined: Running firefox with the -screenshot command line argument will be broken
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See original bug
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The only changes to shipping code are bundling a new jsm and modifying code that is only loaded/run when -screenshot is present in the command line arguments.
  • String changes made/needed: none
Attachment #9082157 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Comment on attachment 9082157 [details]
Bug 1569135 Fix --screenshot r=kmag

Fixes a regression in 69 causing the --screenshot flag to be broken. Approved for 69.0b13.

Attachment #9082157 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attached image Linux.png

Hi Andrew,

I've been trying to reproduce this bug but I have a problem. As you can see in my screenshot, I've installed version 69.0b12 to first try and reproduce this bug. When I run the command <./firefox -p> to execute FF, it does so without problems. As seen, it opens version 69.ob12. However, when I try to take the screenshot the console is trying to take the screenshot of version 68.0.1.

This way, I can't reproduce the bug nor verify if it's fixed since it always takes the screenshot of version 68.0.1, regardless of the version I've downloaded.
Is there a way around or is this a problem with firefox?
Best regards, Flor.

Flags: needinfo?(aswan)

It looks like you just need to use ./firefox instead of firefox when running the tests with the -screenshot argument?

Flags: needinfo?(andrew.swan)

Hi Andrew,

Thanks a lot for the help! I've been able to reproduce the bug on older versions and I've been able to take the screenshot on the latest nightly 70.0a1 (2019-08-16) (64-bit) and latest beta 69.0b13 (64-bit). Therefore, I've changed the status of the bug to verified fixed.

Best regards, Flor.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.