Having had to update from 128.14.0esr-1~deb11u1 I notice a
regression with regards to the size of the Firefox window.

My setup is a laptop with 1024×768 px resolution running
evilwm, a window manager that adds only a one-pixel border
around windows but allows the border to be offscreen.

What I want, for Firefox, is for the window to be as big
as possible, that is, 1024×768 content and the border offscreen.

I can get that by wm-fullscreening with Ctrl-Alt-X, but
unfortunately, Firefox has always interpreted that as the
same as F11 for firefox-fullscreening with menu bar hiding,
which I decidedly do *not* want in the normal case (and
trigger manually if needed).

‣‣‣ if there’s a way to disable t̲h̲a̲t̲, I’ll consider it an
    even better fix for my real issue

Up to 128, I could get the window to a good size and
position with:

$ xdotool selectwindow windowmove 0 0 windowsize 1024 768

However, with 140, something is wrong, but I cannot find
the rhyme or reason with it. Even if I toy with things like
windowmove -1 -1 or windowsize 1025 769 or 1026 770, it
either draws a border or hides one column of pixels from the
window content. And, funnily enough, sometimes if I move to
a different virtual workspace and back, it doesn’t even draw
the border so a row and a column of background shine through.

(Mostly, I want it as large as possible, so that I get the
maximum viewport into websites, and flush with the right and
bottom margin of the screen so I can move the mouse there to
the very end and consistently click the scrollbar. If it has
a window border at the top and left, I’d accept that.)

When I hold Ctrl-Alt-I to obtain window geometry, Firefox
reports nonsensical values (574x648+0+0).

Even after starting, it renders the window in a weird state:
window border top and left, shine-through of the background
(one pixel) bottom and right. In that state we get…

tg@x61p:~ $ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x1800014 "Mozilla Firefox"

  Absolute upper-left X:  1
  Absolute upper-left Y:  1
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1023
  Height: 767
  Depth: 24
  Visual: 0xe1
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1800002 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +1+1  -0+1  -0-0  +1-0
  -geometry 1023x767+0+0

If I then do the xdotool, the window decoration vanishes and
the window moves a pixel to the top left, but the bottom right
is still shine-through. In that state, we have:

tg@x61p:~ $ xwininfo

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x1800014 "Mozilla Firefox"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 1024
  Height: 768
  Depth: 24
  Visual: 0xe1
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x1800002 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 1024x768+-1+-1

I suspect there to be an off-by-one (fencepost) in where the
browser draws its window, somewhere, that is new compared to
earlier versions.

Here’s how that looks. Ignore the menu font, I am running
an experiment wrt. “system-ui” use.

Interestingly enough, with every start, the window moves one pixel
to the down and right, and, consequentailly, shrinks one pixel in
each direction every time, until I resize it, of course. But when
I don’t but start it multiple times, it shrinks.

This all is new and indicates a fencepost error somewhere.

bye,
//mirabilos

found 1115851 140.3.1esr-1~deb11u1
thanks

I found at least a workaround of some sorts:

alias ff='xdotool sleep 5 search --sync --class firefox windowsize %@ 1025 769 windowmove %@ 0 0 & eatmydata firefox-esr'

The five seconds sleep are subject to local experimentation.
Unfortunately, it doesn’t work without (that search --sync
should make it, but perhaps Firefox starts invisible windows
before the main one). The sizing-then-moving makes it use up
the whole screen by giving it a size larger than the screen
(confirming the fencepost issue).

Just in case others stumble on this.