1635927 - Command line options width and height don't work anymore

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Mike Kaply [:mkaply]]

At some point, the width and height command line parameters stopped working.

I tested Firefox 45 and they worked there.

We also show an error on the console about width/height not being supported, but that is spurious - 45 showed that error as well.

Comment 1

[Mike Kaply [:mkaply]]

I've started running some builds to see when this broke.

In 60 everything seems to work mostly (although we have a black status bar at the bottom)

In 65, setting width height works for the very first window, but then it ends up persisting width and height.

So there are probably a number of things broken here.

Comment 2

[Mike Kaply [:mkaply]]

This appears to be a persistence problem. We honor the values on first run, but not on subsequent runs.

But once you delete the xulstore file once, it starts working.

Comment 3

[Dave Townsend [:mossop]]

This is handled by front-end code: https://searchfox.org/mozilla-central/source/browser/components/BrowserContentHandler.jsm#809

Comment 4

[Mike de Boer [:mikedeboer]]

Thanks Dave!

Mike, did you happen to find the regression window in the end? Perhaps the new mozregression is able to help with that? (I'm guessing this is important for kiosk mode?)

Comment 5

[Mike Kaply [:mkaply]]

This has been really difficult to track down because mozregression isn't working properly when passing args. I'm still investigating.

Comment 6

[Ian Moody [:Kwan] (UTC+1)]

(In reply to Mike Kaply [:mkaply] from comment #5)

This has been really difficult to track down because mozregression isn't working properly when passing args. I'm still investigating.

Could you expand on that?
In what way is it not working properly?
And how are you passing the args?

Comment 7

[Mike Kaply [:mkaply]]

In my testing, passing the args on the command line did not work consistently. In older versions of Firefox it did. I own doing more testing on this, it just hasn't been a priority.

Comment 9

[Mike Kaply [:mkaply]]

So I did some more testing and I really don't have anything to add beyond what I posted earlier. Here are very specific details to recreate.

Start an old Firefox (I used Firefox 45). Multiple times, like this:

firefox -height 1000 -width 1000
firefox -height 500 -width 500
firefox -height 1000 -width 1000
firefox -height 500 -width 500

Every time Firefox is started, it honors the height and width so it goes between the two sizes.

In current versions of Firefox, the height/width is honored on a new profile, but subsequent width/height is ignored.

So if you do the same sequence as above, it is always 1000x1000 even when you pass 500x500

I'm not sure how to track this down with mozregression since it requires multiple starts of the same profile.

Comment 10

[Bogdan Maris, Desktop QA]

I think I found the issue here. So it appears to be related to the notification dialog windows (close multiple tabs, default firefox etc). If any of those is displayed when closing Firefox, the new command with the new height/width will be ignored. If no dialog is displayed (close each tab until close, or disable the multiple close tab dialog before closing Fx) each change in height/width will be recorded.

How I tested (windows 10) to reproduce:

• Latest Nightly:
  -- run firefox -height 1000 -widht 1000 -p
  -- create a new profile
  -- Start Nightly (make sure to have at least 2 tabs)
  -- Close Nightly (close dialog will appear)
  -- Click Close Tabs inside close dialog
  -- run firefox -height 500 -width 500 -p
  -- select the same profile as above
  -- window still has -height 1000 -width 1000

How I bypassed this (windows 10):

• Latest Nightly:
  -- run firefox -height 1000 -widht 1000 -p
  -- create a new profile
  -- Start Nightly
  -- Disable the Default browser check (change value of browser.shell.checkDefaultBrowser to false)
  -- Disable the Close tabs check (change value of browser.tabs.warnOnClose to false)
  -- Close Nightly
  -- run firefox -height 500 -width 500 -p
  -- select the same profile as above
  -- window now respects the -height 500 -width 500

This is indeed an old regression from 2018 and I think I found a range here (had to manually find it): https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=68464218a41a5350ffa926e1b5d77fde75bc4e01&tochange=7771df14ea181add1dc4133f0f5559bf620bf976
Not sure what bug might have caused this.

Comment 12

[Ian Moody [:Kwan] (UTC+1)]

(In reply to Mike Kaply [:mkaply] from comment #9)

So I did some more testing and I really don't have anything to add beyond what I posted earlier. Here are very specific details to recreate.

Start an old Firefox (I used Firefox 45). Multiple times, like this:

firefox -height 1000 -width 1000
firefox -height 500 -width 500
firefox -height 1000 -width 1000
firefox -height 500 -width 500

Every time Firefox is started, it honors the height and width so it goes between the two sizes.

In current versions of Firefox, the height/width is honored on a new profile, but subsequent width/height is ignored.

So if you do the same sequence as above, it is always 1000x1000 even when you pass 500x500

I'm not sure how to track this down with mozregression since it requires multiple starts of the same profile.

So I think the best way to do this with mozregression is with a second terminal for the subsequent launches
In the first terminal run mozregression with mozregression -b 2018-01-01 --arg="--width=500" --arg="--height=500" (args that start with a hyphen-minus require quoting like that)
Once firefox launches just close it, then in the first terminal look for the line INFO: Application command: which will be followed by something like /tmp/tmpijx5fh1g/firefox/firefox --width=500 --height=500 -profile /tmp/tmphetdi2in.mozrunner
Copy that and paste it into the second terminal and add --no-remote (otherwise it clashes with my main running firefox for me, I'm guessing mozregression/mozrunner is doing that automatically but not reflecting it there), and adjust the dimensions to 1000 then run it. Then depending on the result return to the first terminal and give mozregression the good or bad answer. This works because it doesn't clean up the tmp directories for the binary and profile until said answer is given.

Using this I got a regression range of https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68464218a41a5350ffa926e1b5d77fde75bc4e01&tochange=8bf380faae74e4921be6000496ca09d4a2c44e8d, which is a superset of the one from comment #10 (I'm curious how bogdan ended up with an autoland range, given the lack of builds from back then).

In my range (but not bogdan's) bug 1446264 looked most suspicious, though it was backed out in the same range, so dead end there.

But I've just noticed "Bug 1447719 - Set browser.startup.blankWindow to true on Windows and Linux" f026ead5dbfce9d6530429ac568ecc5544cc9b3b and if I do mozregression -g 2018-03-20 -b 2018-03-23 --arg="--width=500" --arg="--height=500" --pref "browser.startup.blankWindow:false" I can no longer reproduce on "bad" builds, until I go in the the temp profile's user.js and toggle browser.startup.blankWindow back to true, so I think we have our regressor.

Comment 13

[Florian Quèze [:florian]]

Given that it took years for this regression to be reported, does it mean it's a feature receiving very little use that we don't to support?

I'm forwarding the needinfo to Doug who's working in bug 1665451 on a new version of what I did for quantum with the early blank window.

Comment 14

[Mike Kaply [:mkaply]]

Given that it took years for this regression to be reported, does it mean it's a feature receiving very little use that we don't to support?

It's become more important now that we have kiosk mode. We definitely don't want to remove support as it's needed for parity with Chrome.

Comment 15

[Mike Kaply [:mkaply]]

The reason it matter for kiosk mode is window positioning on specific monitors (that's broken too).

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Console' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 17

[:Gijs (he/him)]

(In reply to Florian Quèze [:florian] from comment #13)

Given that it took years for this regression to be reported, does it mean it's a feature receiving very little use that we don't to support?

I'm forwarding the needinfo to Doug who's working in bug 1665451 on a new version of what I did for quantum with the early blank window.

The skeleton UI will turn itself off when any commandline switch not in this set is used, so I think it should cope with the width/height - we'll just not show the skeleton UI, which is fine for the kiosk mode consumers that we care about here.

The regressor being bug 1446264 and that being Core DOM : Core & HTML means that I think we should move this bug too, to have a better chance of finding someone who's able to address this. Frontend is still passing the right info at https://searchfox.org/mozilla-central/rev/3407e72ceb5039da514c03ae61bd279b1725c3b2/browser/components/BrowserContentHandler.jsm#769-770 , and that should be overriding the XUL persist and/or other info that DOM/window management code uses/has.

Comment 18

[:Gijs (he/him)]

... actually moving the bug this time.