Bug 1542668 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Notes from a quick look over the source + wr-capture:

The wr-capture indeed specifies the document size as 16 pixels taller than the window seemingly should be. However this is compensated by *something*, as we see several items in the wr display list have a position of (xxx, 16). You can visually see this as the tab separators abruptly end before this odd lump.

The document size is acquired from nsWindow(?)::GetClientSize, however there is also GetClientBounds and GetClientOffset (not documented well enough for me to understand exactly), but they all bottom out into winapi calls like ClientToScreen. I haven't verified this yet (need to do a fresh windows build), but I expect that in the case where we're maximized *and* the toolbar is on top, the window has an extra 16px of height that is compensated by GetClientOffset.

So the question I need to answer is whether the bug is: 

* inappropriately setting the size of the window
* inappropriately getting the size of the window (GetClientSize instead of GetClientBounds?)
* failing to explain to webrender that these pixels should just be transparent

Sotaro: ever seen this before, and/or any idea which component should be considered wrong?
Notes from a quick look over the source + wr-capture:

The wr-capture indeed specifies the document size as 16 pixels taller than the window seemingly should be. However this is compensated by *something*, as we see several items in the wr display list have a position of (xxx, 16). You can visually see this as the tab separators abruptly end before this odd lump.

The document size is acquired from nsWindow(?)::GetClientSize, however there is also GetClientBounds and GetClientOffset (not documented well enough for me to understand exactly), but they all bottom out into winapi calls like ClientToScreen. I haven't verified this yet (need to do a fresh windows build), but I expect that in the case where we're maximized *and* the toolbar is on top, the window has an extra 16px of height that is compensated by GetClientOffset.

So the question I need to answer is whether the bug is: 

* incorrectly **setting** the size of the window
* incorrectly **getting** the size of the window (GetClientSize instead of GetClientBounds?)
* failing to explain to webrender that these pixels should just be transparent

Sotaro: ever seen this before, and/or any idea which component should be considered wrong?

Back to Bug 1542668 Comment 9