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.
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Version: unspecified → Trunk
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...
If this happens at startup time, please nominate this bug to block Thunderbird 3; otherwise please nominate it as wanted.
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.
Severity: normal → minor
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.
(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!
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.
(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.
Assignee: nobody → jminta
Severity: minor → normal
Whiteboard: [fix in hand; see comment 7]
Target Milestone: --- → Thunderbird 3.0rc1
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".
Created attachment 373548 [details] [diff] [review] Fix
Assignee: jminta → philringnalda
Status: NEW → ASSIGNED
Attachment #373548 - Flags: review?(jminta)
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.
Created attachment 373595 [details] [diff] [review] 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.
Attachment #373595 - Flags: review?(jminta) → review?(mkmelin+mozilla)
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.
Attachment #373595 - Flags: review?(mkmelin+mozilla) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fix in hand; see comment 7]
Target Milestone: Thunderbird 3.0rc1 → Thunderbird 3.0b3
You need to log in before you can comment on or make changes to this bug.