User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.18 Safari/537.36 Steps to reproduce: I have a multi (3) monitor setup, not sure how relevant this is. Snap Thunderbird to a window edge, I used the left side, so WindowsKey+Left Arrow to do that. I have Thundebird on the right one of the 3 monitors. Shutdown your computer Start your computer Start Thunderbird Actual results: Thunderbird was not exactly snapped to the edge anymore, instead it was a few pixels away from the edge. Expected results: Thunderbird should have restored in the snapped state.

Does Firefox store the snapped state? If not, please file a bug for Firefox or move this bug to the Firefox queue. Thunderbird uses window management from common Mozilla core modules. I could well imagine that the window size and position is reinstated but not the snap state.

(In reply to Jorg K [Almost not working on Thunderbird (some bustage-fix only) due to non-renewal of contract] from comment #1) > Does Firefox store the snapped state? If not, please file a bug for Firefox > or move this bug to the Firefox queue. > > Thunderbird uses window management from common Mozilla core modules. I could > well imagine that the window size and position is reinstated but not the > snap state. stan?

Sorry, missed the reply. Firefox does in fact restore the snap state correctly. It seems to have some special code to do it. If I start it up again after closing, it restores in the "wrong" position but then snaps itself back into position after a split second.

Sorry, I don't have expertise in this area

Rob can you reproduce? If so, please change status to new

Who would be able to confirm this? I can still repro it on 61.0a1 (2018-03-21) (64-bit).

I can't but maybe rctgamer3 can

Tested this with both Thunderbird and Firefox. Both reopen a couple of pixels from the screen border (likely default Windows behaviour, probably the window size + shadow width). However, Firefox fixes this, but Thunderbird doesn't.

Yeah that is exactly what I am seeing. Thanks for confirming.

Richard, any idea where we should start looking?

Unfortunately not. Maybe a regression window where FX was fixed or TB regressed could help.

Jim, are you aware of any code in Firefox that deals with the window snap state that we could port to TB? Looks like FF is handling it well and TB doesn't.

Can you reproduce with nightly from https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ ? Find a regression range?

I tested with a recent nightly (62.0a1 (2018-05-19) (64-bit)) and it is still broken there.

(In reply to Jorg K (GMT+2) (bustage-fix only, NI for urgent reviews) from comment #12) > Jim, are you aware of any code in Firefox that deals with the window snap > state that we could port to TB? Looks like FF is handling it well and TB > doesn't. it's all down in nsWindow, I'd suggest turning on the native message debugging and looking at that code for clues.

Still broken with newest Daily (2018-06-03)

Still broken with 63.0a1 (2018-07-25) (64-bit)

I think I have seen this as well, slightly different, but it could be the same issue. Thunderbird 60.0 64-bit on windows. Start with a new profile by first deleting the Thunderbird folders in Roaming and Local. Maximise Thunderbird, close thunderbird, reopen, it is not maximised anymore. With Thunderbird 52.9.1 all was well. We use some code to copy xulstore.json to a new profile. This works fine, without this code this issue is also there. After closing thunderbird we look into the xulstore.json in the profile: > "messengerWindow":{"screenX":"0","screenY":"0","width":"2560","height":"1052","sizemode":"maximized"}, But it doesn't respect this setting! You can even make an empty xulstore.json with only this line: >{"chrome://messenger/content/messenger.xul":{"messengerWindow":{"sizemode":"maximized"}}} And it will not maximise the window.

Of course I found the cause of my issue: privacy.resistFingerprinting was set to true. Perhaps the reporter has this same issue?

(In reply to jjurkus from comment #19) > Of course I found the cause of my issue: > privacy.resistFingerprinting was set to true. > > Perhaps the reporter has this same issue? privacy.resistFingerprinting is set to false here