Update details open in a message window as editable HTML

RESOLVED FIXED in Thunderbird 20.0

Status

Thunderbird
Preferences
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: Ehsan, Assigned: standard8)

Tracking

Thunderbird 20.0
Dependency tree / graph
Bug Flags:
wanted-thunderbird +
blocking-thunderbird3 -

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

STR:

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?
(Assignee)

Updated

8 years ago
Depends on: 532675
(Assignee)

Comment 1

8 years ago
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.
(Assignee)

Updated

8 years ago
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.
(Assignee)

Comment 3

8 years ago
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: --- → ?
status-thunderbird3.0: --- → wanted
Flags: blocking-thunderbird3? → blocking-thunderbird3-
(Assignee)

Comment 4

7 years ago
This is broken UI, so I think it is needed, but due to its hidden state, not critical for .1.
blocking-thunderbird3.0: ? → needed
(Assignee)

Comment 5

7 years ago
Clearing wanted as this is needed.
status-thunderbird3.0: wanted → ---
Duplicate of this bug: 606847

Comment 7

7 years ago
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?

Thanks!
(Assignee)

Comment 8

7 years ago
(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.
(Assignee)

Updated

7 years ago
blocking-thunderbird3.0: needed → -
blocking-thunderbird5.0: --- → ?
(Assignee)

Updated

6 years ago
blocking-thunderbird5.0: ? → -
Flags: wanted-thunderbird+
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Updated

6 years ago
Whiteboard: [has core patch][maybe needs TB3.0/191 version]
Duplicate of this bug: 777232
(Assignee)

Updated

4 years ago
Depends on: 263433
(Assignee)

Comment 10

4 years ago
Created attachment 696890 [details] [diff] [review]
The fix

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
Status: NEW → ASSIGNED
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 (!linkHandled.data) {
> +      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 (!linkHandled.data) {

Instead of checking this again, I think I'd prefer if, after we set linkHandled.data = true on line 123, we return early. Then, after 125, we can assume that both linkHandled.data is false, and that we weren't able to open a tab in a pre-existing 3pane window.
Attachment #696890 - Flags: review?(mconley) → review+
(Assignee)

Comment 12

4 years ago
Checked in with comments addressed:

https://hg.mozilla.org/comm-central/rev/bc6d82e4d41f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 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.