The default bug view has changed. See this FAQ.

Site Navigation Bar misses its tooltip when minimized

VERIFIED FIXED in seamonkey2.14

Status

SeaMonkey
UI Design
--
trivial
VERIFIED FIXED
9 years ago
5 years ago

People

(Reporter: sgautherie, Assigned: tonymec)

Tracking

({polish})

Trunk
seamonkey2.14
polish
Bug Flags:
in-testsuite -

SeaMonkey Tracking Flags

(seamonkey2.11 wontfix, seamonkey2.12 fixed, seamonkey2.13 fixed, seamonkey2.14 verified)

Details

(Whiteboard: [good first bug][mentor=Ratty(Phil.Chee)][lang=xul][level=beginner] , URL)

Attachments

(2 attachments, 5 obsolete attachments)

1.86 KB, patch
tonymec
: review+
tonymec
: feedback+
Details | Diff | Splinter Review
1.11 KB, patch
tonymec
: review+
tonymec
: feedback+
neil@parkwaycc.co.uk
: approval-comm-aurora+
neil@parkwaycc.co.uk
: approval-comm-beta+
Details | Diff | Splinter Review
(Reporter)

Description

9 years ago
(Found while testing bug 401552)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008061402 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Other minimized (tool)bars have a tooltip displaying their name;
S.N.B. has none.
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.2pre) Gecko/20110518 Firefox/4.0.2pre SeaMonkey/2.1.1pre

Happens on Linux too => Platform to "All".
Tentatively moving to UI Design. Please move to Themes if it doesn't happen in Modern theme (I tested only with Classic).
Assignee: general → nobody
Component: General → UI Design
OS: Windows 2000 → All
QA Contact: general → ui-design
Hardware: x86 → All
Whiteboard: [SmBugEvent]

Comment 2

6 years ago
I cannot seem to reproduce?
WinXP x86, (Windows) Classic Theme


Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14

Comment 3

6 years ago
Changing to (Windows) XP Theme made no difference.
I still see the tooltips?

Comment 4

5 years ago
The Link toolbar (website navigation toolbar) just needs a "grippytooltiptext" attribute set e.g.
grippytooltiptext="Website Navigation Bar"

Updated

5 years ago
Whiteboard: [SmBugEvent] → [SmBugEvent][good first bug][mentor=Ratty/Phil.Chee][lang=xul][level=beginner]
(Reporter)

Comment 5

5 years ago
(In reply to therube from comment #2)
> I cannot seem to reproduce?

(In reply to therube from comment #3)
> I still see the tooltips?

Unexpected. What does the S.N.B. tooltip read? (Maybe attach a screenshot.)

*****

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14] (release)
[Mozilla/5.0 (Windows NT 5.0; rv:13.0a1) Gecko/20120201 Firefox/13.0a1 SeaMonkey/2.10a1] (nightly, 2012-02-01-00-30-09-comm-central-trunk)

Bug still there (with Classic theme).
Flags: in-testsuite-

Comment 6

5 years ago
> Changing to (Windows) XP Theme made no difference.
> I still see the tooltips?

STR:
1. View -> Show/Hide->Website Navigation Bar -> Show always.
2. Collapse the WNB (links) toolbar.
3. Hover your mouse over the collapsed grippy.

Updated

5 years ago
Whiteboard: [SmBugEvent][good first bug][mentor=Ratty/Phil.Chee][lang=xul][level=beginner] → [SmBugEvent][good first bug][mentor=Ratty(Phil.Chee)][lang=xul][level=beginner]

Comment 7

5 years ago
> The Link toolbar (website navigation toolbar) just needs a "grippytooltiptext"
> attribute set e.g. |grippytooltiptext="Website Navigation Bar"|

The link toolbar is here in case anyone wants to fix this:
http://hg.mozilla.org/comm-central/annotate/4d1465a48f5a/suite/browser/linkToolbarOverlay.xul#l56
Created attachment 645301 [details] [diff] [review]
patch v0
Comment on attachment 645301 [details] [diff] [review]
patch v0

:-? If it was so simple, why didn't anybody do it? Everything was in the bug comments.

...And BTW I can still see the bug in the following build:
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14a1 ID:20120723003021 CSet: 433268decbc6 m-c: 82b6c5885345
Attachment #645301 - Flags: review?(philip.chee)
Since this fix includes a new localizable string, it won't be ported back to versions earlier than current trunk.
status-seamonkey2.13: --- → wontfix
status-seamonkey2.14: --- → affected
Created attachment 645303 [details] [diff] [review]
patch v0.1

This version uses an existing string.
Attachment #645301 - Attachment is obsolete: true
Attachment #645301 - Flags: review?(philip.chee)
Attachment #645303 - Flags: review?(philip.chee)
status-seamonkey2.13: wontfix → ---
Comment on attachment 645303 [details] [diff] [review]
patch v0.1

It's not quite that simple, you have to use the name of the string (the bit after <!ENTITY in the .dtd file) wrapped in & and ; characters. (This assumes that the .dtd file that you're using is already listed in the <!DOCTYPE> declaration.)
Attachment #645303 - Flags: review?(philip.chee) → review-
(In reply to neil@parkwaycc.co.uk from comment #12)
> Comment on attachment 645303 [details] [diff] [review]
> patch v0.1
> 
> It's not quite that simple, you have to use the name of the string (the bit
> after <!ENTITY in the .dtd file) wrapped in & and ; characters. (This
> assumes that the .dtd file that you're using is already listed in the
> <!DOCTYPE> declaration.)

I thought there was a hitch. OK let's go find it.
http://mxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/browser/linkToolbar.dtd#6

and it is listed at http://hg.mozilla.org/comm-central/annotate/4d1465a48f5a/suite/browser/linkToolbarOverlay.xul#l8
Created attachment 645324 [details] [diff] [review]
patch v0.2 (Aurora and earlier)
Attachment #645303 - Attachment is obsolete: true
Attachment #645324 - Flags: review?(neil)
Comment on attachment 645324 [details] [diff] [review]
patch v0.2 (Aurora and earlier)

This seems acceptable as a branch hack (although you'd still need approval).

However I notice that all of our other grippy tooltips use the form
<toolbar id="someToolbar" grippytooltiptext="&someToolbar.tooltip;"> so I'll request KaiRo's feedback as to what localisers would expect us to do.
Attachment #645324 - Flags: review?(neil)
Attachment #645324 - Flags: review+
Attachment #645324 - Flags: feedback?(kairo)
Hm, "Menu Bar" is not present in the View→Show/Hide menu, while "Bookmarks Toolbar" and "Navigation Toolbar" use (at least in en-US) the same string for menuitem and tooltip. It would be possible (for 2.14 and later) to modify the DTD (creating a second entity with the same text) but wouldn't it be, er, in French we would say "se chatouiller pour se faire rire" (tickling oneself to make oneself laugh)? Reusing the same string ensures consistency.
Assignee: nobody → antoine.mechelynck
Status: NEW → ASSIGNED

Comment 18

5 years ago
> However I notice that all of our other grippy tooltips use the form
> <toolbar id="someToolbar" grippytooltiptext="&someToolbar.tooltip;">

For branch we should take this. For trunk we should create a new entity and use that.

> with the same text) but wouldn't it be, er, in French we would say "se chatouiller pour
> se faire rire" (tickling oneself to make oneself laugh)? Reusing the same string
> ensures consistency.
It may not be the same string in *all* languages. In fact it's almost a certainty that some language or other has some peculiar rule or special case.
Attachment #645324 - Attachment description: patch v0.2 → patch v0.2 (Aurora and earlier)
Created attachment 645660 [details] [diff] [review]
patch v1.0 (comm-central ONLY)

OK, here's the patch for trunk, with distinct strings for label and tooltip.
Attachment #645660 - Flags: review?(neil)
Attachment #645660 - Flags: feedback?(kairo)
Comment on attachment 645660 [details] [diff] [review]
patch v1.0 (comm-central ONLY)

> <!-- Link Toolbar Title -->
> <!ENTITY linkToolbar.label "Website Navigation Bar">
>+<!ENTITY linkToolbar.tooltip "Website Navigation Bar">
> <!ENTITY linkToolbar.accesskey "a">
linkToolbar.label and linkToolbar.accesskey go on the same DOM element, so they should not be split apart by the new entity. r=me with that fixed.
Attachment #645660 - Flags: review?(neil) → review+
Created attachment 645675 [details] [diff] [review]
patch v1.1 (comm-central ONLY) r=neil
Attachment #645660 - Attachment is obsolete: true
Attachment #645660 - Flags: feedback?(kairo)
Attachment #645675 - Flags: review+
Attachment #645675 - Flags: feedback?(kairo)

Comment 22

5 years ago
Comment on attachment 645675 [details] [diff] [review]
patch v1.1 (comm-central ONLY) r=neil

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

::: suite/locales/en-US/chrome/browser/linkToolbar.dtd
@@ +7,3 @@
>  <!ENTITY linkToolbar.label "Website Navigation Bar">
>  <!ENTITY linkToolbar.accesskey "a">
>  

Style nit: I'd put the .tooltip entry after the other two, just for logic.
Attachment #645675 - Flags: feedback?(kairo) → feedback+

Updated

5 years ago
Attachment #645324 - Flags: feedback?(kairo) → feedback+
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #22)
> Comment on attachment 645675 [details] [diff] [review]
> patch v1.1 (comm-central ONLY) r=neil
> 
> Review of attachment 645675 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: suite/locales/en-US/chrome/browser/linkToolbar.dtd
> @@ +7,3 @@
> >  <!ENTITY linkToolbar.label "Website Navigation Bar">
> >  <!ENTITY linkToolbar.accesskey "a">
> >  
> 
> Style nit: I'd put the .tooltip entry after the other two, just for logic.

I thought the two occurrences of the string belonged next to each other, and Neil wanted title & accesskey together; but no prob, I'll make the change.
Created attachment 646434 [details] [diff] [review]
patch v1.2 (comm-central ONLY) r+=neil f+=kairo

carrying flags forward from v1.1
Attachment #645675 - Attachment is obsolete: true
Attachment #646434 - Flags: review+
Attachment #646434 - Flags: feedback+
setting checkin-needed, please push only patch v1 (attachment #646434 [details] [diff] [review]) and only to comm-central.

If no problems and after approval we'll take care of the branches.
Keywords: checkin-needed
Whiteboard: [SmBugEvent][good first bug][mentor=Ratty(Phil.Chee)][lang=xul][level=beginner] → [c-n: only v1, to comm-central]
Comment on attachment 645324 [details] [diff] [review]
patch v0.2 (Aurora and earlier)

[Approval Request Comment]
Regression caused by (bug #): unknown.
    Problem existed in SeaMonkey 2.0a1pre (2008-06-14) and possibly earlier.
User impact if declined: trivial: missing tooltip on a grippy
Testing completed (on m-c, etc.):
    checkin-needed shall not happen before VERIFIED on trunk.
Risk to taking this patch (and alternatives if risky): minimal (IMHO none)
String changes made by this patch: none

This is the "simplified" version (with no new strings) of the patch now ready for trunk (which has one new string, albeit identical in en-US to an existing string).
Attachment #645324 - Flags: approval-seamonkey2.1?
Attachment #645324 - Flags: approval-seamonkey2.0.15?
Attachment #645324 - Flags: approval-comm-release?
Attachment #645324 - Flags: approval-comm-beta?
Attachment #645324 - Flags: approval-comm-aurora?
Callek and/or ewong: I'm not sure how far back the fix can be ported. Feel free to deny any "exaggerated" approval request.

Comment 28

5 years ago
Comment on attachment 645324 [details] [diff] [review]
patch v0.2 (Aurora and earlier)

approval‑seamonkey2.* should actually be retired, we don't care about those old branches any more.
This also doesn't warrant landing in a potential chemspill, so - for release.
We are early in the beta cycle and this is basically zero risk, so I'll grant it there, but if we'd be later in the cycle, this wouldn't be enough win to risk any change at all there.
Attachment #645324 - Flags: approval-seamonkey2.1?
Attachment #645324 - Flags: approval-seamonkey2.0.15?
Attachment #645324 - Flags: approval-comm-release?
Attachment #645324 - Flags: approval-comm-release-
Attachment #645324 - Flags: approval-comm-beta?
Attachment #645324 - Flags: approval-comm-beta+
Attachment #645324 - Flags: approval-comm-aurora?
Attachment #645324 - Flags: approval-comm-aurora+
https://hg.mozilla.org/comm-central/rev/d23b0fba5ed6

Hi Tony, to make life easier for those checking in on your behalf, please make sure your future patches include all the needed metadata. Thanks!
https://developer.mozilla.org/en/Creating_a_patch_that_can_be_checked_in
Keywords: checkin-needed
Whiteboard: [c-n: only v1, to comm-central]
Target Milestone: --- → seamonkey2.14
(In reply to Ryan VanderMeulen from comment #29)
> https://hg.mozilla.org/comm-central/rev/d23b0fba5ed6
> 
> Hi Tony, to make life easier for those checking in on your behalf, please
> make sure your future patches include all the needed metadata. Thanks!
> https://developer.mozilla.org/en/Creating_a_patch_that_can_be_checked_in

ah, I forgot the -m argument to qrefresh. Thanks for reminding me.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: seamonkey2.14 → ---
status-seamonkey2.11: --- → wontfix
status-seamonkey2.12: --- → affected
status-seamonkey2.13: --- → affected
status-seamonkey2.14: affected → fixed
Created attachment 646452 [details] [diff] [review]
patch v0.2.1 (Aurora and earlier) r=Neil (patch with enhanced metadata)

Carrying flags over from patch v0.2
No changes in the code
Added #Author and patch title in what "man patch" calls the leading garbage.

Do Not Yet Push.
Attachment #645324 - Attachment is obsolete: true
Attachment #646452 - Flags: review+
Attachment #646452 - Flags: feedback+
(Reporter)

Updated

5 years ago
status-seamonkey2.14: fixed → ---
Target Milestone: --- → seamonkey2.14
Attachment #645324 - Attachment is obsolete: false
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 SeaMonkey/2.14a1 ID:20120726184449 c-c: d23b0fba5ed6 m-c: f528e021ceb1

Testing the first hourly build with the fix using the STR in comment #6.

It has the tooltip (the latest nightly didn't). Otherwise it works just as well AFAICT.

In the meantime I have cloned comm-aurora and comm-beta and verified that attachment #646452 [details] [diff] [review] (patch v0.2.1) applies cleanly on their respective "default" branch tips.

Please push attachment #646452 [details] [diff] [review] (or attachment #645324 [details] [diff] [review]) to comm-aurora and comm-beta.

Note: As anyone can verify by clicking "Details" on them, both these attachments have identical code, but one of them has the approvals while the other has the metadata.
Status: RESOLVED → VERIFIED
Keywords: checkin-needed
Whiteboard: [c-n: see comment #32]
Comment on attachment 646452 [details] [diff] [review]
patch v0.2.1 (Aurora and earlier) r=Neil (patch with enhanced metadata)

[Triage Comment]
Transferring KaiRo's approvals.
Attachment #646452 - Flags: approval-comm-beta+
Attachment #646452 - Flags: approval-comm-aurora+
(Reporter)

Updated

5 years ago
Attachment #645324 - Attachment is obsolete: true

Comment 34

5 years ago
Pushed:
http://hg.mozilla.org/releases/comm-aurora/rev/780fa44fb8fd
http://hg.mozilla.org/releases/comm-beta/rev/1a9d3dfb1c97
status-seamonkey2.12: affected → fixed
status-seamonkey2.13: affected → fixed
status-seamonkey2.14: --- → fixed
Whiteboard: [c-n: see comment #32]
Keywords: checkin-needed
status-seamonkey2.14: fixed → verified

Updated

5 years ago
Whiteboard: [good first bug][mentor=Ratty(Phil.Chee)][lang=xul][level=beginner]
You need to log in before you can comment on or make changes to this bug.