Closed Bug 532567 Opened 13 years ago Closed 10 years ago

Update details open in a message window as editable HTML


(Thunderbird :: Preferences, defect)

Not set


(blocking-thunderbird5.0 -, blocking-thunderbird3.0 -)

Thunderbird 20.0
Tracking Status
blocking-thunderbird5.0 --- -
blocking-thunderbird3.0 --- -


(Reporter: ehsan.akhgari, Assigned: standard8)




(1 file)


1. Go to Preferences.
2. Go to Advanced > Update.
3. Click Show Update History.
4. Click on a Details link.

What happens:
The update details page opens up in a message window as editable HTML, which is definitely what the user didn't originally want.

What should happen:
The update details page should open in a new content tab.
Flags: blocking-thunderbird3?
Flags: in-litmus?
Depends on: 532675
Part of the issue for us, is that toolkit is being inconsistent with this text link and isn't ending up using its openURL function in contentAreaUtils.js.

I've got a patch I'm working on for the core issue (in bug 532675). I'm not sure if we'll get it into 1.9.1 or not, if we don't then I have to figure out a way of fixing the binding from within TB.
Whiteboard: [has core patch][maybe needs TB3.0/191 version]
I'm not terribly confident about a fix in mail/ - on non-Mac we could probably set browser.chromeURL to something that knows how to deal, since there we've got nothing to lose (the details link, and anything that follows the same path, hits a fallback for not having a browser.chromeURL pref and tries to load chrome://navigator/content/navigator.xul which we don't have), but on OS X we have it set to the compose window so that clicking a mailto link when we're running with no open windows doesn't do something ugly like open a 3pane and then open a compose window from that. I've thought about solving the whole "foo opens a compose window" (where foo certainly includes feed subscription from a browser, and probably more) by switching to having the hidden window know how to deal and using it as a browser.chromeURL dispatcher, but that very much doesn't feel like a stable-branch fix.
From the chat amongst drivers we're not going to block on the original issue of opening the log incorrectly as it is unlikely to be frequently especially as most people are unlikely to find this bit of UI.

Finding some sort of generic solution would be nice, but we may just have to go with the specific solution that I'll propose in bug 532675.
blocking-thunderbird3.0: --- → ?
Flags: blocking-thunderbird3? → blocking-thunderbird3-
This is broken UI, so I think it is needed, but due to its hidden state, not critical for .1.
blocking-thunderbird3.0: ? → needed
Clearing wanted as this is needed.
Duplicate of this bug: 606847
this bug has been found almost 1 year now, why it's still there? Maybe just to change the open "details" link in the browser (system default), simple and easy, isn't it?

(In reply to comment #7)
> this bug has been found almost 1 year now, why it's still there? Maybe just to
> change the open "details" link in the browser (system default), simple and
> easy, isn't it?

No, it isn't that simple. There's a set of interactions going on here that are difficult to work around.
blocking-thunderbird3.0: needed → -
blocking-thunderbird5.0: --- → ?
blocking-thunderbird5.0: ? → -
Flags: wanted-thunderbird+
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [has core patch][maybe needs TB3.0/191 version]
Duplicate of this bug: 777232
Depends on: 263433
Attached patch The fixSplinter Review
With the recent changes in bug 263433, this is actually quite easy to do and provides a really easy way for us to do the right thing.

Once we land this, we can also re-examine other places where we use text-link and have an onclick handler that calls openURL, but I can file a follow-up for those.
Assignee: nobody → mbanner
Attachment #696890 - Flags: review?(mconley)
Comment on attachment 696890 [details] [diff] [review]
The fix

Review of attachment 696890 [details] [diff] [review]:

r=me with the following changes. Thanks Mark!

::: mail/components/mailGlue.js
@@ +113,5 @@
> +  _handleLink: function MailGlue__handleLink(aSubject, aData) {
> +    let linkHandled = aSubject.QueryInterface(Ci.nsISupportsPRBool);
> +    if (! {
> +      let win = Services.wm.getMostRecentWindow("mail:3pane");
> +      let tabParams = { contentPage: aData, clickHandler: null};

Nit - space before }, for consistency.

@@ +124,5 @@
> +        }
> +      }
> +
> +      // If we didn't have an open 3 pane window, try and open one.
> +      if (! {

Instead of checking this again, I think I'd prefer if, after we set = true on line 123, we return early. Then, after 125, we can assume that both is false, and that we weren't able to open a tab in a pre-existing 3pane window.
Attachment #696890 - Flags: review?(mconley) → review+
Checked in with comments addressed:
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 20.0
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.