Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 Application Build ID 20120819030208 When I launch Thunderbird trunk after having it closed while being maximized, the new window shows the 'maximized' icon in the top right corner, but the window doesn't stretch to the bottom. There is some space free at the bottom, showing other windows. This is likely caused by the title bar rewrite/hack.

Could this be a dupe of bug 783710? Last good 20120815 First bad 20120816 This could also point to bug 697230 like in bug 783710 suspected. When mail.tabs.drawInTitlebar is on false then no problem. If on true the gap on the bottom looks like the height of the titlebar

I forgot, I tested on Win7.

Bug shows in Winxp also

(In reply to Joe Sabash from comment #4) > Bug shows in Winxp also Confirmed with XP as well.

Seeing this on Win 7. Starting investigation.

So it's not clear to me *why* this patch fixes things, but removing the guard that checks that the resize event is happening on the current window seems to solve the problem. That having been said, I don't feel great about removing a guard I don't understand. Dao, you've worked on the Firefox version of TabsInTitlebar, and what we have is a pretty similar port. Can you shed any light on why we're hitting this bug, why my patch fixes it, and if my patch is the way forward? -Mike

Comment on attachment 653447 [details] [diff] [review] Patch v1 >- window.addEventListener("resize", function (event) { >+ window.addEventListener("resize", function(aEvent) { Not sure what the point of this change is... >- if (event.target != window) >- return; >- TabsInTitlebar.allowedBy("sizemode", true); >+ let sizemode = document.documentElement.getAttribute("sizemode"); >+ TabsInTitlebar.allowedBy("sizemode", sizemode == "maximized"); There are two behavior changes here. Which one actually fixes this bug? allowedBy("sizemode", true) being called unconditionally surely doesn't seem to make sense and wasn't in line with the Firefox code, so if correcting this fixes this bug, that's good.

(In reply to Dão Gottwald [:dao] from comment #8) > > >- if (event.target != window) > >- return; > >- TabsInTitlebar.allowedBy("sizemode", true); > >+ let sizemode = document.documentElement.getAttribute("sizemode"); > >+ TabsInTitlebar.allowedBy("sizemode", sizemode == "maximized"); > > There are two behavior changes here. Which one actually fixes this bug? > allowedBy("sizemode", true) being called unconditionally surely doesn't seem > to make sense and wasn't in line with the Firefox code, so if correcting > this fixes this bug, that's good. The change that corrected the behaviour was when I removed these lines: if (event.target != window) return;

It shouldn't. If it does, there's probably something fishy going on.

(In reply to Dão Gottwald [:dao] from comment #10) > It shouldn't. If it does, there's probably something fishy going on. Hrm, then yes, something fishy IS going on. :/ Not sure where to begin diagnosing it, but I'll keep poking and prodding.

Since the regression range falls outside of any work that occurred wrt the tabs in titlebars, I have to assume that this is a regression caused by changes in mozilla-central. Bisecting now.

Bisecting (and necessary skipping due to broken builds) has given me the following candidate changesets: changeset: 102463:448410c2035e user: Neil Deakin <neil@mozilla.com> date: Wed Aug 15 14:52:42 2012 -0400 summary: Bug 743975 - use a widget listener interface instead of the remaining events that don't need an event, changeset: 102464:4aca82dc0d41 user: Neil Deakin <neil@mozilla.com> date: Wed Aug 15 14:52:42 2012 -0400 summary: Bug 743975 - add a getpresshell method to the widget listener, r=tn changeset: 102465:54badf5d08b0 user: Neil Deakin <neil@mozilla.com> date: Wed Aug 15 14:52:42 2012 -0400 summary: Bug 743975 - Remove events that are now unused, r=smaug changeset: 102466:e66c290ab9fc user: Neil Deakin <neil@mozilla.com> date: Wed Aug 15 14:53:09 2012 -0400 summary: Bug 743975 - remove the event handler argument to widget creation methods, r=tn changeset: 102467:dfcc0507902c user: Neil Deakin <neil@mozilla.com> date: Wed Aug 15 14:53:14 2012 -0400 summary: Bug 743975 - remove the view wrapper,r=tn

Reorder these calls as there were before bug 743975.

Verified in Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 (20120825030543) Thanks Neil!

Still present on Windows 10 (x64) (Thunderbird 45.4.0).

Also seeing something similar to this, on Windows 10 (x64) Thunderbird 52.5.0 (32-bit). 1. Set Thunderbird to occupy the left-hand side of the screen using the Windows key in conjunction with the left arrow key. 2. Close Thunderbird. 3. Re-open Thunderbird When launched there will be a small gap between the top of the taskbar and the bottom edge of the Thunderbird window, and the left-hand edge of the screen and the left-hand edge of the Thunderbird window.