Open Bug 83578 Opened 23 years ago Updated 15 years ago

Differentiate between status bar text from UI and from Web pages (blind links)

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: keith, Unassigned)

References

(
URL
)

Details

I saw "Processing your request. Please wait." in the status bar, and I didn't
know if it was a Mozilla thing or if the current site put it there when I
clicked "Submit." Maybe some kind of icon or color change or font change
(italics or something?) would make it more apparent where the text came from.
Definitely not JS engine.  Over to UI design.
Assignee: rogerl → mpt
Status: UNCONFIRMED → NEW
Component: Javascript Engine → User Interface Design
Ever confirmed: true
QA Contact: pschwartau → zach
Adding extra icons would be odd if they weren't clickable (like all the other
icons in the status bar are), and italics are unreadable in some fonts commonly
used for status bar text (e.g. Geneva).

So, I suggest:
*   Where the font normally used in the status bar is of regular weight (the
    normal case), use bold weight for status text placed by the Web page.
*   Where the font normally used in the status bar is of bold weight, use
    regular weight for the status text placed by the Web page.

I guess the right way to do this is to give remote status text a
pseudo-selector, and theme that.

--> XP Apps: GUI
Assignee: mpt → blake
URL: http://holloway.co.nz/book/3/third.html
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Summary: it should be obvious somehow whether the current text in the status bar is from the current site or if it is a Mozilla message → Differentiate between status bar text from UI and from Web pages
QA Contact: sairuh → claudius
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 43791 has been marked as a duplicate of this bug. ***
[Aufbau-P3]: Turning "blind links" into normal links would be very nice for porn
surfing.
Summary: Differentiate between status bar text from UI and from Web pages → Differentiate between status bar text from UI and from Web pages (blind links)
Whiteboard: [Aufbau-P3]
Whiteboard: [Aufbau-P3]
Do we still need this now that we have a pref to prevent scripts from messing
with the status bar?
Marking WONTFIX. You can prevent web pages from overriding your status bar text
by going to Scripts & Windows/Scripts & Plugins and unchecking "Change status
bar text".
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
uh, this bug wasn't "I don't want javascript to override the status bar," it was
"I want to know when the status bar was set by mozilla or by javascript"
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
And my question in comment 5 was why this would still be necessary?
let's say you're at some site, and let's say it's geocities.com/happylove, and
it says "Click here for my happy fun page" and you run your mouse over it and
it's geocities.com/happyfun. So you click on it and it's kiddie porn at
www.kiddieporn.com and then your kids are in the room and they see you looking
at it and they're scarred for life. all this because some javascript set the
status bar to "geocities.com/happyfun." Obviously there are more plausible
examples, but this one certainly gets the point across. and no, it is not a
valid solution to disable javascript from editing the status text, because then
you would miss important javascript status messages. thus, discriminating
between javascript and browser status bar text is very important.

How about this:
when the mouse hovers over a link and
when js can modify the status text (js on and modify status text on)
then a little tooltip comes up with the address of that link or "Links to 
http://foo.bar.com/porn.html" or something or possibly the status bar expands 
upwards to display the link address. First one is better imho.

That would be better than just differentiating between a link and js setting the 
status bar text IMO.

Should I submit another enhancement request?
personally I like your option 2 better, because a link can have a TITLE= and
then how would the tooltip work? Would the tooltip display both the TITLE and
"Links to ___"?
I guess the tooltip could have both on 2 lines. I'm not sure if the expanding 
statusbar could be done nicely, but could look cool if done properly. Also the 
link properties dialog would already have the title, so showing it may or may 
not be needed.

How 'bout some feedback from XUL & UI people?
I agree that this is moot since you can prevent the browser from changing the
statusbar with javascript.  Turn it off and no more blind links.  
As I said in comment 9, you'd miss other, possibly important, Javascript status
bar messages. For example, while editing a page, the MoinMoin Wiki shows a
countdown until your edit lock expires in the status bar, with JavaScript.
Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). 
If you want this fixed for Firefox, change the Product and Component accordingly
and reassign back to me.
Assignee: firefox → guifeatures
Status: REOPENED → NEW
Target Milestone: Future → ---
Product: Core → Mozilla Application Suite
Blocks: 325274
*** Bug 298903 has been marked as a duplicate of this bug. ***
> I agree that this is moot since you can prevent the browser from changing the
> statusbar with javascript.  Turn it off and no more blind links.  

Not exactly.  What if a site changes the link's href onmousedown?
QA Contact: claudius
(In reply to comment #17)
> > I agree that this is moot since you can prevent the browser from changing the
> > statusbar with javascript.  Turn it off and no more blind links.  
> 
> Not exactly.  What if a site changes the link's href onmousedown?
> 

I suppose the onmousedown function would still be javascript, and "nasty" at that; but if disabled, some users might complain, "this-and-that link on such-and-such page is not behaving as it should".
Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: guifeatures
Component: XP Apps: GUI Features → UI Design
A suggestion might be to add a plugin, call it Sight Lock, a little button added to the toolbar to toggle Sight Lock on or off. The function simply to bring up a warning message: "You are about to leave the Sight domain.com", and possibly adding buttons for continue, or go back.
Did you mean "site lock"?

I'm not sure what that would accomplish?
Such would help stop Blind Links, Blind Redirects, Java Redirects, etc. For example, say you are clicking on a thumbnail thinking you are going to see a bigger picture, instead it takes you to another domain loaded with spam, popups, malware, etc.

And no I mean Sight, if I can't reach in and touch the girls they are only a Sight. On Site, yum, touch, hold, hug... :) But alass, we can only enjoy the Sights.
You need to log in before you can comment on or make changes to this bug.