486430 - Mail Start Page disappears after right click

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[skierpage]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090401 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2

If I right-click in the Mail Start Page, the next left-click makes it go away.

Reproducible: Always

Steps to Reproduce:
1. In a tab or in three-pane view, choose Go > Mail Start Page.
2. Right-click in this window
3. Left-click anywhere -- on a menu item, in the window, even elsewhere on the desktop.
Actual Results:  
The pane stops displaying "Welcome to Thunderbird" and goes back to previous contents.

Expected Results:  
Work like other windows.

If you clicked on a context menu item, the action seems to complete (e.g. you copy the link's URL or save it), but you're still taken from the page.

I'm finding lots of other minor glitches with the this Mail Start Page and the similar "What's new in Thunderbird 3" first-time tab (bug 486427) -- try all the menu items -- but I won't have time to file them all.

Comment 1

[Joshua Cranmer [:jcranmer]]

Confirmed on Linux 2009-04-04. This is most likely a regression from the new message pane changes; it's definitely a regression from 2.0.

I am going to guess either bug 455801 or bug 449641 is implicated here, which means it should have started regressing with the 2008-09-17 nightly. dmose, any thoughts?

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Interestingly, I don't see this behavior on Mac 2009-04-16.

Does this happen at startup time, or only when explicitly going to the page via the menu item?

skierpage, out of curiousity, were you motivated to use the "Go > Mail Start Page" only because you needed to describe "steps to reproduce"?  Or do you ever actually use the menu item in day-to-day use?  If the latter, I'd be interested to understand more about your use case...

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

If this happens at startup time, please nominate this bug to block Thunderbird 3; otherwise please nominate it as wanted.

Comment 4

[Wayne Mery (:wsmwk)]

windows XP
works 080916  080927(has URL start page) - this rules out bug 455801)
works 081213 (new folder pane)
fails 20090112031756
      the L-click context menu on home page is different - it has tag, delete 
      message, etc which should only be given for messages

I'd guess whatever patch changed message pane/c-menu is causing this. someone will need to narrow it further.  

re: startup - 20090416 startup is OK. R-click then L-click doesn't kill start page. It's only when you first select a message, then start page, that you see this behavior. What's new is not affected.

note also, in 090216 alt+home brings up home page in one shot.
between there and 090303 it requires two alt+home to bring it up - the first alt+home only blanks the message pane.

Comment 5

[Phil Ringnalda (:philor)]

You should find your regression window around 2009-01-04 18:12 PDT, then.

My first guess would be RestoreSelectionWithoutContentLoad(), but setting a breakpoint there just gets Venkman all hot and bothered about how you're trying to talk to it while a context menu is still up.

Comment 6

[skierpage]

(In reply to comment #2)
> skierpage, out of curiousity, were you motivated to use the "Go > Mail Start
> Page" only because you needed to describe "steps to reproduce"?

Initially I used it because I wanted to get back to the "What's new in Thunderbird 3" first-time tab and that menu item seemed the most likely route.  I doubt I'll use Mail Start Page on an ongoing basis.  But experiencing these glitches in my first 5 minutes of TB3 use made me distrust TB3's message/tab behavior... (so this is a medium-priority polish bug?).  Thanks for caring!

Comment 7

[Phil Ringnalda (:philor)]

Ah, SeaMonkey didn't port this bug when they were porting because Neil spotted it - bug 469498 comment 19 (with alternate STR that don't call for Go - Start Page), we do indeed need to not RestoreSelectionWithoutContentLoad() when we aren't a threadpane context menu.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #6)
>
> Initially I used it because I wanted to get back to the "What's new in
> Thunderbird 3" first-time tab and that menu item seemed the most likely route. 
> I doubt I'll use Mail Start Page on an ongoing basis.  

I'm still trying to get a feel for the use cases here.  What was it that motivated you to want to see that page again after the initial display of it had passed?

> But experiencing these glitches in my first 5 minutes of TB3 use made me 
> distrust TB3's message/tab behavior... (so this is a medium-priority polish
> bug?).

If we think lots of people actually follow the usage pattern that you did, perhaps.  I'd be a little surprised if that were true, but it's not like we have any real data here.  Since we don't have data, I'm trying to understand your motivations better in order to try and reason about this a bit more easily.

However, clarkbw pointed out to me yesterday that another use case for that menu item is for people who set their start page to something other than the default (eg the New York Times), and this would break that workflow painfully, so I'm bumping it up to normal priority.

In most cases, I'd suggest that we probably wouldn't actually block on this bug if it were the last one standing.  But since it's fairly disconcerting behavior for the use case clarkbw described, and since we appear to have a trivial, tested fix in-hand, I'm marking it as blocking+.

My interpretation of the bug history here is that it's a regression from a patch of jminta's, so I'm starting off by assigning to him in the hopes that he'll find the time to mark it ASSIGNED and take a run at it.  However, if someone else reading this decides they want to grab it first, I bet that'll make Joey pretty happy.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

And by "take a run at it", I really just mean "generate a patch as described by comment 7 and drive it into the tree".

Comment 10

[Phil Ringnalda (:philor)]

Attachment: Fix

Comment 11

[Joey Minta]

Comment on attachment 373548 [details] [diff] [review]
Fix

Is there any reason for keeping the if (event.target == this) check in the xul? Seems like we can easily move it to the new function to make things cleaner.

Bonus points for adding documentation above each function.

Comment 12

[Phil Ringnalda (:philor)]

Attachment: Fix v.2

Moving it at least made me learn what it's doing, and thus learn that we really want to be doing the same thing onpopupshowing, since currently we're rebuilding the whole nsContextMenu every time a submenu opens. I'm sort of moderately sure that event.target != event.currentTarget is what we want to be checking, but not quite sure enough to push it without first sharing any possible blame.

Comment 13

[Magnus Melin [:mkmelin]]

Comment on attachment 373595 [details] [diff] [review]
Fix v.2

Looks good to me! r=mkmelin

>+/**
>+ * Determines whether the context menu was triggered by a node that's a child
>+ * of the threadpane by looking for a parent node with id="threadTree".
>+ */
>+function popupNodeIsInThreadPane()

Nit: add @return doxygen comment too.

Comment 14

[Phil Ringnalda (:philor)]

http://hg.mozilla.org/comm-central/rev/31f0ca6b816e