Closed Bug 467012 Opened 16 years ago Closed 16 years ago

Opening mails in message window gives only a blank window

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: Nomis101, Assigned: standard8)

References

Details

(Keywords: regression)

Attachments

(1 file, 3 obsolete files)

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.
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?
Keywords: regression
I can see this. Could be Mac specific. I'll take a look in a while.
Flags: blocking-thunderbird3+
Target Milestone: --- → Thunderbird 3.0b1
Version: unspecified → Trunk
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.0b1?
Flags: blocking-thunderbird3+
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.
OS: Mac OS X → All
Hardware: Macintosh → All
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?
(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.
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3.0b1?
Flags: blocking-thunderbird3+
Flags: blocking-thunderbird3.0b1?
Note: blocking-thunderbird3 and a milestone of 3.0b1 is what we are using for blocking beta 1.
Flags: blocking-thunderbird3.0b1?
Attached patch WIP (obsolete) — Splinter Review
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.
Whiteboard: [needs help - Philor?]
> 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.
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.
Joe: Can you test in a fresh new profile? or reset your toolbar to defaults.
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"
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...
yes, the downloaded build has the same issue. I'm hoping that we can work around the regression caused by the mozilla-central change.
Attached patch possible fix (obsolete) — Splinter Review
this gets the message window working, at least.
Attachment #350545 - Flags: review?(bugzilla)
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.
(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);
  }
)
(In reply to Comment #17)

Joe, try deleting or renaming localstore.rdf (and/or test in -safe-mode)
Bug 407725 was backed out from m-c, so this should be gone now.
Blocks: 407725
Whiteboard: [needs help - Philor?] → [wfm by bug 407725 backout?]
(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.
No longer blocks: 407725
Depends on: 407725
(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.
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
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.
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
Blocks: 407725
No longer depends on: 407725
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.
Attachment #350545 - Flags: review?(bugzilla)
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?
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
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 :)
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.
Assignee: nobody → bugzilla
Attachment #350497 - Attachment is obsolete: true
Attachment #350545 - Attachment is obsolete: true
Whiteboard: [wfm by bug 407725 backout?]
Assignee: bugzilla → nobody
Whiteboard: [wfm by bug 407725 backout?]
Whiteboard: [wfm by bug 407725 backout?]
(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.
(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.
Assignee: nobody → bugzilla
Attached patch The fixSplinter Review
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.
Attachment #351581 - Attachment is obsolete: true
Attachment #352101 - Flags: review?(philringnalda)
Attachment #352101 - Flags: review?(mkmelin+mozilla)
(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).
Attachment #352101 - Flags: review?(mkmelin+mozilla) → review+
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.
Attachment #352101 - Flags: review?(philringnalda)
Landed fix (bug 407725 has also landed): http://hg.mozilla.org/comm-central/rev/74c522b5c9bb
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.