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

RESOLVED FIXED in seamonkey2.1final

Status

defect
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: stefanh, Assigned: stefanh)

Tracking

(Blocks 1 bug, {regression})

Trunk
seamonkey2.1final
x86
macOS
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(blocking-seamonkey2.1 final+)

Details

Attachments

(2 attachments)

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).
I think this should block 2.1. I don't think the value added by fixing bug 39113 outweights this regression.
blocking-seamonkey2.1: --- → ?
(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).
> (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.
(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).
The most reasonable thing to do here is probably to stop using the pane labels to set the prefwindow title.
(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!
blocking-seamonkey2.1: ? → final+
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 on attachment 530655 [details] [diff] [review]
2.0 backout (no .dtd changes)

Review of attachment 530655 [details] [diff] [review]:
-----------------------------------------------------------------
Attachment #530655 - Flags: review?(bugspam.Callek)
Callek, in case you need this landed while I'm not around: Here's a changeset patch with user info/commit message.
Attachment #530655 - Flags: review?(bugspam.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.
Attachment #530699 - Flags: review+
http://hg.mozilla.org/comm-central/rev/813c489a99d0
http://hg.mozilla.org/releases/comm-2.0/rev/ef507802e7e9
Assignee: nobody → stefanh
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.1final
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.