Thunderbird doesn't launch maximized, not full height, empty space at bottom

VERIFIED FIXED in Thunderbird 17.0

Status

Thunderbird
Toolbars and Tabs
VERIFIED FIXED
5 years ago
6 months ago

People

(Reporter: aryx, Assigned: Neil Deakin)

Tracking

Trunk
Thunderbird 17.0
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

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.

Updated

5 years ago
Duplicate of this bug: 783710

Comment 4

5 years ago
Bug shows in Winxp also

Comment 5

5 years ago
(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.
Assignee: nobody → mconley
Created attachment 653447 [details] [diff] [review]
Patch v1

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
Attachment #653447 - Flags: feedback?(dao)
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.
Attachment #653447 - Flags: feedback?(dao)
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
Blocks: 743975

Updated

5 years ago
Duplicate of this bug: 784570
(Assignee)

Comment 15

5 years ago
Created attachment 654295 [details] [diff] [review]
Notify the view for resize events before the webshellwindow

Reorder these calls as there were before bug 743975.
Assignee: mconley → enndeakin
Attachment #653447 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Attachment #654295 - Flags: review?(jmathies)

Updated

5 years ago
Attachment #654295 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/e048ac9eb279
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 17.0

Comment 17

5 years ago
Verified in Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0a1 (20120825030543)
Thanks Neil!
Status: RESOLVED → VERIFIED

Comment 18

6 months ago
Still present on Windows 10 (x64) (Thunderbird 45.4.0).
You need to log in before you can comment on or make changes to this bug.