467012 - Opening mails in message window gives only a blank window

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Nomis101]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; de-de) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081127 Shredder/3.0b1pre

Since today I get only a blank window if I try to open a mail in the message window by double clicking it. I doesn't have this issue in a version of thunderbird I build right after checkin of "Follow up to bug 456818". So it must have to do with changes after that.

Trying to open the message window gives me also two new errors in the error console:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER)"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://messenger/content/messageWindow.js :: HideToolbarButtons :: line 417"  data: no]

and

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIControllers.removeController]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://messenger/content/messageWindow.js :: UnloadCommandUpdateHandlers :: line 1151"  data: no]

I doesn't see this error in the yesterday build. The first error could be Bug 466751.

Reproducible: Always

Steps to Reproduce:
1. Double click on a mail to open it.
2.
3.
Actual Results:  
The opening window is blank.


I also have this issue if I start in safe mode.

Comment 1

[Magnus Melin [:mkmelin]]

WFM over here using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081127 Lightning/1.0pre Shredder/3.0b1pre

Anything to add to the steps to reproduce?

Comment 2

[Mark Banner (:standard8)]

I can see this. Could be Mac specific. I'll take a look in a while.

Comment 3

[Mark Banner (:standard8)]

I can reproduce on my local debug build (i.e. with + without Lightning).

The first error mention is on opening the window. The second error is on closing it, which isn't surprising as I expect the whole window hasn't started up correctly.

Its not the follow up to bug 456818 as that was a css only change.

At the moment, the error points to this line of code:

    toolbarPalette.removeChild(toolbarPalette.getElementsByAttribute('id', 'mailviews-container')[0]);

I'm not sure how that can be returning NS_ERROR_INVALID_POINTER.

That makes me realise: I only see this if I've got the mail views widget on the main mail toolbar.

Comment 4

[Rain [:rain1] (inactive)]

I can easily reproduce with a debug 20081127 build on Vista. For me, it doesn't even matter whether the mail views widget is on my toolbar or not.

Comment 5

[Magnus Melin [:mkmelin]]

If toolbar stuff is causing this, bug 407725 did land on m-c in the timeframe... Or did it? The gecko id doesn't contain hours anymore?

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #4)
> I can easily reproduce with a debug 20081127 build on Vista. For me, it doesn't
> even matter whether the mail views widget is on my toolbar or not.

I agree now. On my main profile I see this with or without the mail view widget. This is definitely a blocker in that case.

Though I wonder if due to bug 407725 our customise code and toolkits is out of sync enough hence what is causing the breakage.

Comment 7

[Mark Banner (:standard8)]

Note: blocking-thunderbird3 and a milestone of 3.0b1 is what we are using for blocking beta 1.

Comment 9

[Mark Banner (:standard8)]

Attachment: WIP

I locally bscked out bug 407725 and confirmed that is the source of the regression.

I have tried porting the changes from that patch, however this still doesn't work, so I expect there is something else wrong somewhere.

I'm hoping Phil might be able to take a look at this and get an idea of where the problem may lie.

Comment 10

[Philip Chee]

> At the moment, the error points to this line of code:

>     toolbarPalette.removeChild(toolbarPalette.getElementsByAttribute('id',
> 'mailviews-container')[0]);

> I'm not sure how that can be returning NS_ERROR_INVALID_POINTER.

Well now we don't clone nodes on to the toolbar.We move nodes to/from the toolbar so if the button is on the toolbar it isn't in the palette.

Comment 11

[Joe Sabash [:JoeS1]]

Not seeing this in WinXP with build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081128 Lightning/1.0pre Shredder/3.0b1pre ID:20081128031313

Might be a clue that I use "text only" as a toolbar option.

Comment 12

[Philip Chee]

Joe: Can you test in a fresh new profile? or reset your toolbar to defaults.

Comment 13

[Joe Sabash [:JoeS1]]

Set toolbars to default, and tried "new window" Vs "existing window"
Still cannot reproduce in WinXP
I'll ask in the forums, but this might not be platform "all"

Comment 14

[David :Bienvenu]

I had no problem reproducing it on windows with my own debug build, so I suspect it is platform all. I'll try a downloaded build...

Comment 15

[David :Bienvenu]

yes, the downloaded build has the same issue. I'm hoping that we can work around the regression caused by the mozilla-central change.

Comment 16

[David :Bienvenu]

Attachment: possible fix

this gets the message window working, at least.

Comment 17

[Joe Sabash [:JoeS1]]

Odd to be fussing over a build not failing :)
But trying with a different profile, I can reproduce.
If it's any help, I could compare the 2 profiles.
Might have something to do with modified privileges, or an exposed protocol.

Comment 18

[Philip Chee]

(In reply to Comment #16)

+    try {
+      var toolbarPalette = document.getElementById('mail-toolbox').palette;
+      toolbarPalette.removeChild(toolbarPalette.getElementsByAttribute('id', 'search-container')[0]);

I think you only need the try block around the "search_container" since the rest are non-default e.g.

    var toolbarPalette = document.getElementById('mail-toolbox').palette;
    try {
      toolbarPalette.removeChild(toolbarPalette.getElementsByAttribute('id', 'search-container')[0]);
    }
    ...

OR perhaps (pseudocode):

var toolbarPalette = document.getElementById('mail-toolbox').palette;
['search-container', 'mailviews-container' ...].forEach(function (element, index, array) {
  let node = toolbarPalette.getElementsByAttribute('id', element)[0];
  if (node)
    toolbarPalette.removeChild(node);
  }
)

Comment 19

[Philip Chee]

(In reply to Comment #17)

Joe, try deleting or renaming localstore.rdf (and/or test in -safe-mode)

Comment 20

[Magnus Melin [:mkmelin]]

Bug 407725 was backed out from m-c, so this should be gone now.

Comment 21

[Mark Banner (:standard8)]

(In reply to comment #20)
> Bug 407725 was backed out from m-c, so this should be gone now.

If it is we should leave this open for when that bug re-lands, though we can take it off the blocking list. New nightlies will be out in an hour or two.

Comment 22

[Nomis101]

(In reply to comment #20)
> Bug 407725 was backed out from m-c, so this should be gone now.
Oh yes, I doesn't get a blank window anymore in a recent build.

Comment 23

[[e-mail]]

The problem didn't affect people who had customised their toolbar because in that case the search-container wasn't in the current set and it therefore existed in the palette.

One solution is to just null-check looking for the search-container in the palette (the other buttons will still be in the palette because they're not in the default set.)

Another option is to overlay each of the toolbars manually, then you can set different defaultset attributes for messenger.xul and messageWindow.xul

Comment 24

[ar]

FYI (might be helpful or give a clue):

Version:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081125 Lightning/1.0pre Shredder/3.0b1pre
does not have this problem.

All the nest, starting with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081126 Lightning/1.0pre Shredder/3.0b1pre
do have it.

My toolbar is customized long-long time.

Comment 25

[ar]

Everything is alright in today's update for Windows:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081130 Lightning/1.0pre Shredder/3.0b1pre
Thanks

Comment 26

[Mark Banner (:standard8)]

Comment on attachment 350545 [details] [diff] [review]
possible fix

From what has already been said, I think we should try adjusting the overlays rather than doing this patch.

Comment 27

[David :Bienvenu]

I'm going to leave this open, but move to b2. We should edit the summary to reflect what we want to change, I think - suggestions?

Comment 28

[Robert Kaiser]

The original patch that caused this in in mozilla-central again and seems to be sticking, I expect we'll push to get it approved for 1.9.1 soon. If you can adjust your code in a way that it works without and with that change, you might want to try and do that soon so you won't break again. And people building theirselves can easily test with mozilla-central :)

Comment 29

[Mark Banner (:standard8)]

Attachment: Separate out main mail window specific items

This is what I'm currently looking at - split the relevant items into their own overlay.

The general idea seems to work, and I thought I had the customize sheets coming up once, however they seem to be broken now, and the main mail window gives me an error that I can't see where its coming from.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #9)
> Created an attachment (id=350497) [details]
> WIP

You probably do want to land this patch too, even if it might be unnecessary to fix this bustage. The toolkit parts of the patch for bug 407725 rely on it.

Comment 31

[Mark Banner (:standard8)]

(In reply to comment #30)
> (In reply to comment #9)
> > Created an attachment (id=350497) [details] [details]
> > WIP
> 
> You probably do want to land this patch too, even if it might be unnecessary to
> fix this bustage. The toolkit parts of the patch for bug 407725 rely on it.

Yes I probably do - I'd forgotten that when I marked it obsolete.

Comment 32

[Mark Banner (:standard8)]

Attachment: The fix

This patch combines the first patch which synced the js code (i.e. copied the changes in bug 407725) and the patch for the separation of the main mail window specific items, as well as fixing a couple of issues with the syncing.

I have checked on Mac and Windows that this works to the same extent as customising toolbars does currently (i.e. see bug 407725 and others).

SeaMonkey would like to land bug 407725 on mozilla-1.9.1 asap, therefore requesting a couple of reviewers so that we can make this happen (maybe by tomorrow?). I'll take the first appropriate review I get.

Comment 33

[Mark Banner (:standard8)]

(In reply to comment #32)
> I have checked on Mac and Windows that this works to the same extent as
> customising toolbars does currently (i.e. see bug 407725 and others).

That was meant to be:

I have checked on Mac and Windows that this works, with the patch from bug 407725 applied, to the same extent as customising toolbars does currently (e.g. see bug 468056 and others).

Comment 34

[Magnus Melin [:mkmelin]]

Comment on attachment 352101 [details] [diff] [review]
The fix

Works fine on linux too. 

r=mkmelin with the tabs removed (at least 3 of them)

Unticking the composition toolbar, and reopening the composition window I do get a 

Error: customizePopup is null
Source File: chrome://messenger/content/mailCore.js
Line: 59

... but that's already there before this patch.

Comment 35

[Mark Banner (:standard8)]

Landed fix (bug 407725 has also landed): http://hg.mozilla.org/comm-central/rev/74c522b5c9bb