Last Comment Bug 341278 - Status bar priority
: Status bar priority
Status: RESOLVED FIXED
: fixed1.8.1.1
Product: Camino Graveyard
Classification: Graveyard
Component: Toolbars & Menus (show other bugs)
: unspecified
: PowerPC Mac OS X
-- minor (vote)
: ---
Assigned To: Stuart Morgan
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-12 12:15 PDT by acoolie
Modified: 2006-11-06 08:08 PST (History)
1 user (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
prioritize status strings (8.35 KB, patch)
2006-10-24 23:00 PDT, Stuart Morgan
bugzilla-graveyard: review+
mikepinkerton: superreview+
Details | Diff | Splinter Review
with comments (8.39 KB, patch)
2006-11-06 08:07 PST, Stuart Morgan
no flags Details | Diff | Splinter Review

Description User image acoolie 2006-06-12 12:15:03 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060427 Camino/1.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.3) Gecko/20060427 Camino/1.0.1

When loading a page, Camino shows things such as "Connecting to..." and others. These messages are helpful usually, but when trying to find out where a link goes (A feature normally implemented in Camino), it is quite hard to see. The instant a new connection is made, the href of the link goes away. Basically, I feel that link location should have priority over most other messages in the status bar.

Reproducible: Always

Steps to Reproduce:
1. Go to google.com (Or maybe a page that takes longer to load)
2. Quickly hover over a link

Actual Results:  
The link location quickly disappears.

Expected Results:  
The link location should stay in place until mouseout.
Comment 1 User image Stuart Morgan 2006-10-18 09:39:52 PDT
Confirming.  This should be reasonable to do, since it looks like the link information is coming in through setStatus:OfType, whereas the various loading strings are coming from onLoadingStarted/onLoadingCompleted/onStatusChange:.

Taking.
Comment 2 User image Stuart Morgan 2006-10-24 23:00:20 PDT
Created attachment 243442 [details] [diff] [review]
prioritize status strings

fix
Comment 3 User image Stuart Morgan 2006-10-25 10:22:19 PDT
>+  eStatusLinkTarget    = 0, // like mouseover info

That should read 'link mouseover info'; I'll fix that on respin after it's reviewed.
Comment 4 User image Chris Lawson (gone) 2006-10-27 22:24:13 PDT
Comment on attachment 243442 [details] [diff] [review]
prioritize status strings

r=cl. Looks good.

>-  mTabTitle = [mLoadingStatusString retain];
>+  mTabTitle = [NSLocalizedString(@"TabLoading", @"") retain];

This doesn't require any string changes, does it?

cl
Comment 5 User image Stuart Morgan 2006-10-27 22:54:49 PDT
Comment on attachment 243442 [details] [diff] [review]
prioritize status strings

Nope, same string we've always used.
Comment 6 User image Mike Pinkerton (not reading bugmail) 2006-11-06 06:53:28 PST
Comment on attachment 243442 [details] [diff] [review]
prioritize status strings

sr=pink

in the .h, |mStatusStrings| should have a comment that it's a strong (owning) reference.
Comment 7 User image Stuart Morgan 2006-11-06 08:07:51 PST
Created attachment 244807 [details] [diff] [review]
with comments

As checked into trunk and MOZILLA_1_8_BRANCH

Note You need to log in before you can comment on or make changes to this bug.