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

NEW
Unassigned

Status

enhancement
18 years ago
10 years ago

People

(Reporter: keith, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

18 years ago
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
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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 43791 has been marked as a duplicate of this bug. ***

Comment 4

18 years ago
[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]

Updated

18 years ago
Whiteboard: [Aufbau-P3]

Comment 5

17 years ago
Do we still need this now that we have a pref to prevent scripts from messing
with the status bar?

Comment 6

17 years ago
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
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
Reporter

Comment 7

17 years ago
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 → ---

Comment 8

17 years ago
And my question in comment 5 was why this would still be necessary?
Reporter

Comment 9

17 years ago
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.

Comment 10

17 years ago
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?
Reporter

Comment 11

17 years ago
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 ___"?

Comment 12

17 years ago
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?

Comment 13

16 years ago
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.  
Reporter

Comment 14

16 years ago
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.

Comment 15

15 years ago
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

Updated

14 years ago
Blocks: 325274

Comment 16

13 years ago
*** Bug 298903 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
> 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

Updated

11 years ago
Component: XP Apps: GUI Features → UI Design

Comment 20

10 years ago
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.

Comment 21

10 years ago
Did you mean "site lock"?

I'm not sure what that would accomplish?

Comment 22

10 years ago
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.