Closed Bug 720225 Opened 10 years ago Closed 10 years ago
click in empty messagepane reopens Mail
News in Browser
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120121 Firefox/12.0a1 SeaMonkey/2.9a1 Build ID: 20120121134101 Steps to reproduce: Select a Mailfolder in Folderpane, do not select a message in Threadpane, so the messagepane is empty. Click in Messagepane. Actual results: The whole MailNews-window reopens(as Tab) in a new Browser-window. The Adressbar shows the link: "chrome://messenger/content/messenger.xul" Expected results: Nothing. Eventually the same Bug causes, that clicking "anywhere" in a RSS-Feed-Message in MailNews opens the the Message directly in the browser.
Last good: 2012-01-19 16:58:00 PDT First bad: 2012-01-20 19:51:00 PDT There may be a problem with summer/winter time.
Confirm this using: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120122 Firefox/12.0a1 SeaMonkey/2.9a1 Well, just a wild guess, but might this be caused by some changes in Tabbed-Browsing (the New Tab Page feature, see Bug 455553)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm seeing this, too. 20120120 nightly was OK, 20120122 broken (wasn't able to check the one in between, but a custom build on 2012-01-21 already had the issue). (In reply to Tobias Fischer from comment #2) > Well, just a wild guess, but might this be caused by some changes in > Tabbed-Browsing (the New Tab Page feature, see Bug 455553)? Nah, that was backed out completely, and still is. I think we should first make sure it was none of the (very few) comm-central changes, then go through the mozilla-central list from that time frame.
Slightly raising severity because simple clicks shouldn't mess things up this badly.
Severity: normal → major
Not too surprisingly I'm also seeing this on Linux. As I already stated on the newsgroups, if the message pane shows the MailNews start page instead of being empty, the page is loaded in a new browser tab when clicked.
OS: Windows 7 → All
Hardware: x86_64 → All
Seems it was c-c changeset 7a34e038ee94 (bug 717587), probably the contentAreaClick.js part.
Backing out changeset 7a34e038ee94 solves the problem.
I was too clever in moving the href test to the loop condition :-(
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #590584 - Flags: review?(iann_bugzilla)
(In reply to email@example.com from comment #8) > Created attachment 590584 [details] [diff] [review] > Proposed patch Works on my new build of SM 2.9a1.
Using: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120123 Firefox/12.0a1 SeaMonkey/2.9a1 with the changes from http://hg.mozilla.org/comm-central/rev/677095a66adf this seems to be fixed (almost for me). The Bug can be closed as "fixed" for now, i think, but I am not the Owner and no real QA. Thx for your fast work Neil.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 590584 [details] [diff] [review] Proposed patch [Checkin: Comment 11] http://hg.mozilla.org/comm-central/rev/677095a66adf
Attachment #590584 - Attachment description: Proposed patch → Proposed patch [Checkin: Comment 11]
Verified fixed with Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120123 Firefox/12.0a1 SeaMonkey/2.9a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.