648086 - Prefwindow title change from 'Preferences for x profile' to pane title when selecting pane

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Stefan [:stefanh]]

STR:

1) Open Preferences
2) Prefwindow opens, with "Browser" pane selected
3) Prefwindow title says "Preferences for x profile"
4) Select the Advanced pane
5) Prefwindow title says "Advanced"



On mac, we base the prefwindow's title on the pane label

toolkit/content/widgets/preferences.xml
787 #ifdef XP_MACOSX
788           var paneTitle = aPaneElement.label;
789           if (paneTitle != "")
790             document.title = paneTitle;
791 #endif

We also don't show any pane header labels.

We could probably live with not updating the prefwindow title (just show the "Preferences for ..." all the time... or maybe we could append the pane header after the "new" Prefwindow title (could get a bit long, though).

Comment 1

[Stefan [:stefanh]]

I think this should block 2.1. I don't think the value added by fixing bug 39113 outweights this regression.

Comment 2

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #0)
> We could probably live with not updating the prefwindow title (just show the
> "Preferences for ..." all the time... or maybe we could append the pane header
> after the "new" Prefwindow title (could get a bit long, though).

Or we could revert to the old behavior for Mac.

Basically, what we first need is consensus, i.e. what needs to be done, before starting implementation. I suggest you discuss this with Karsten or maybe FF Mac guys since I doubt anyone else on the SM team can tell. Then it should be simple for anyone of us to make the change (a hint regarding how to reliably detect Mac from JS would be helpful, though).

Comment 3

[Philip Chee]

> (a hint regarding how to reliably
> detect Mac from JS would be helpful, though)
/^Mac/.test(navigator.platform) is how we do it in the rest of our js code.

Comment 4

[Stefan [:stefanh]]

(In reply to comment #2)
> Basically, what we first need is consensus, i.e. what needs to be done, before
> starting implementation. I suggest you discuss this with Karsten or maybe FF
> Mac guys since I doubt anyone else on the SM team can tell.

Well, the SM prefwindow is very much non-mac anyway, so there's no "How it should be" here.

I think if we really want to expose the profile name in prefs, we should be consistent across the different platforms. Iotw, we should expose it for mac as well. That said, I don't think it adds any value exposing the profile name (but that's another discussion).

Comment 5

[Stefan [:stefanh]]

The most reasonable thing to do here is probably to stop using the pane labels to set the prefwindow title.

Comment 6

[Justin Wood (:Callek)]

(In reply to comment #1)
> I think this should block 2.1. I don't think the value added by fixing bug
> 39113 outweights this regression.

Agreed. If this is the last blocker for 2.1 we should just back out the offending patch. But I don't want to ship with this bug!

Comment 7

[Stefan [:stefanh]]

Attachment: 2.0 backout (no .dtd changes)

Here's a 2.0-backout that leaves the string changes in. I'd suggest to back this out on trunk as well - I don't really know any good solution to this and not backing it out on trunk will most likely mean that people forget about this.

Comment 8

[Stefan [:stefanh]]

Comment on attachment 530655 [details] [diff] [review]
2.0 backout (no .dtd changes)

Review of attachment 530655 [details] [diff] [review]:
-----------------------------------------------------------------

Comment 9

[Stefan [:stefanh]]

Attachment: Checkin-friendly version of attachment #530655

Callek, in case you need this landed while I'm not around: Here's a changeset patch with user info/commit message.

Comment 10

[Justin Wood (:Callek)]

Comment on attachment 530699 [details] [diff] [review]
Checkin-friendly version of attachment #530655 [details] [diff] [review]

rs+ on backout, based on your word. Also rs+ for a trunk backout, provided you also backout the l10n changes there.

Once the backout(s) are done, resolve this bug and reopen the other.

Comment 11

[Stefan [:stefanh]]

http://hg.mozilla.org/comm-central/rev/813c489a99d0
http://hg.mozilla.org/releases/comm-2.0/rev/ef507802e7e9