Closed
Bug 252811
Opened 21 years ago
Closed 20 years ago
Do not allow hiding of statusbar by default
Categories
(Firefox :: General, defect, P1)
Firefox
General
Tracking
()
RESOLVED
FIXED
Firefox1.0beta
People
(Reporter: richwklein, Assigned: gerv)
References
Details
(Keywords: fixed-aviary1.0)
Attachments
(1 file)
1013 bytes,
patch
|
bugs
:
review+
bugs
:
approval-aviary+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+
With all the talk of url spoofing and phishing we should not allow hiding of the
statusbar by default. IE6 will change to this with service pack 2. It should
only be a change to the pref in firefox.js for us to do it as well. This would
also help with Gerv's Bug 245406.
Reproducible: Always
Steps to Reproduce:
Comment 1•21 years ago
|
||
This may or may not be a dupe of bug 252198, depending on what happens in that bug.
Comment 2•21 years ago
|
||
IMO this bug should block the XUL security bug. Also (IMO) there shouldn't even
be UI in Tools > Options... to enable hiding on the status bar.
Assignee | ||
Comment 3•21 years ago
|
||
I'd prefer it if people couldn't turn off the status bar manually either, but
that might be too controversial. I'd be happy with a patch which just stopped
sites turning it off.
(Thanks for filing this bug, BTW.)
Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•21 years ago
|
||
This patch turns off by default the preferences which allow web pages to hide
the status bar and modify its text.
IMO both are probably needed if we want to say that the status bar is a
reliable way of identifying the source of the window; modifying the main status
text may not be enough to fool the user, but why take the chance? I'm open to
persuasion on this point, however :-)
Gerv
Assignee | ||
Updated•21 years ago
|
Assignee: firefox → gerv
Status: NEW → ASSIGNED
Assignee | ||
Updated•21 years ago
|
Severity: normal → major
Flags: blocking-aviary1.0RC1?
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → Firefox1.0beta
Assignee | ||
Updated•21 years ago
|
Attachment #154296 -
Flags: review?(bugs)
Comment 5•21 years ago
|
||
So you avoid doing something because it might be controversial, and then throw
in another (quite possibly more) controversial change.
Could we not just make this bug about (as the summary says) hiding the status
bar? Widening it out to cover other stuff just reduces the chance of anything
actually happening in time for 1.0.
Assignee | ||
Comment 6•21 years ago
|
||
Michael: I've left it up to ben to decide what to do about this, which I'm sure
he will.
If you can come up with any vital reason why websites should be allowed to
continue modifying the contents of the status bar, let's hear them :-)
Gerv
Comment 7•21 years ago
|
||
Disabling js to change the statusbar text is not making things safer, imho.
It would still be easy to trick a user, for example see this:
<a href="http://google.com"
onclick="this.href='http://www.microsoft.com'">Google</a>
I see the disabling of js to change the statusbar text more as a way to get rid
of annoying status bar tickers.
Assignee | ||
Comment 8•21 years ago
|
||
Disabling the ability for JS to change the status bar is not designed to stop
the user being fooled when clicking a link, it's designed to stop someone trying
to spoof the site name by changing the status bar. Combined with the fact that
it's an irritating feature which is mostly used for evil ;-)
As I said, this may be overkill - I'll let ben decide.
Gerv
Comment 9•21 years ago
|
||
Ok, sorry, I misunderstood.
But someone could still change the statusbartext - even when the
dom.disable_window_status_change pref is set to false - by using dom level 2 events.
See example:
http://home.hccnet.nl/m.wargers/test/mozilla/spoofstatusbar.htm
Comment 10•21 years ago
|
||
> But someone could still change the statusbartext - even when the
> dom.disable_window_status_change pref is set to false - by using dom level 2
> events.
A separate bugzilla entry for this would make sense, I think.
Comment 11•21 years ago
|
||
Attachment #154296 -
Flags: review?(bugs)
Attachment #154296 -
Flags: review+
Attachment #154296 -
Flags: approval-aviary+
See bug 22183.
I don't understand why this helps ... does Firefox usually display the page URL
in the status bar? (Seamonkey doesn't.) Do users look there? What will users
think if there's a spoofed location bar that disagrees with the status bar? I
think I'd trust the location bar myself...
Comment 13•21 years ago
|
||
(In reply to comment #12)
> See bug 22183.
>
> I don't understand why this helps ... does Firefox usually display the page URL
> in the status bar? (Seamonkey doesn't.)
Firefox displays the domain in the status bar next to the lock on secure pages
Comment 14•21 years ago
|
||
roc: Firefox does now display the hostname in the status bar next to the lock
(on the grounds that the location bar can be misleading as the actual
host/domain may not be clear from a URL), and one would hope that users look
down there for the lock (as that is where it has been in the past and in other
browsers). This bug was to finish up that work.
The not-hiding-location-bar idea was an alternative that didn't originally get
moved forward for Firefox. The status bar hostname stuff and this bug were filed
and Gerv's patches approved by Ben before it happened that bug 22183 was
covering Firefox as well as Seamonkey (with blake's dupe and dveditz's patch). I
think either solution is fine, but doing both things seems rather redundant.
OK. That makes sense. I'll comment in bug 22183.
Martjin, can you file that bug?
Comment 17•21 years ago
|
||
(In reply to comment #16)
> Martjin, can you file that bug?
Sure Robret ;), I filed bug 254187 on that.
However, I'm not sure if that's a bug.
It seems logical to me when I create a mouseover event on a link, that the
statusbar changes to contain the href attribute of that link.
Assignee | ||
Comment 18•20 years ago
|
||
Checked in on branch.
Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js
new revision: 1.7.4.20; previous revision: 1.7.4.19
done
Gerv
Comment 19•20 years ago
|
||
As this is fixed on branch, i'm clearing the blocking-flag (and adding "fixed-aviary1.0" keyword)
Flags: blocking-aviary1.0PR?
Keywords: fixed-aviary1.0
Comment 20•20 years ago
|
||
Aviary is regressing this fix by landing the approach at bug 22183, so we will
need a solution to the bug 122445 problem(s) before 1.0.
Comment 21•20 years ago
|
||
This has been relanded on the aviary branch in Bug 259192
Comment 22•20 years ago
|
||
If the purpose of this bug is to prevent spoofing urls in the status bar, then
we should first make sure the correct text is in the status bar for a particular
tab. Making bug 104532 dependant.
Depends on: TabSwitchStatusBar
Comment 23•20 years ago
|
||
This has been fixed by the aviary landing:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/profile/firefox.js&rev=1.35&root=/cvsroot&mark=218-225#215
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
No longer depends on: TabSwitchStatusBar
Resolution: --- → FIXED
Comment 24•20 years ago
|
||
Excuse me for bringing this bug back from the dead, but I really don't see how
disabling "allow scripts to change the status bar text" has anything to do with
security (which was the motive behind this bug).
From comment 8, comment 12, comment 13, and comment 14, I understand that this
was justified in order to prevent sites from spoofing the site name next to the
lock on the status bar on HTTPS pages. However, this seems impossible to do
anyway - as window.status() only sets the text on the left side of the
statusbar, leaving alone the lock and domain name on the right side (I'm on
Mac/Pinstripe - perhaps other themes do this differently?). Try this for
yourself on https://bugzilla.mozilla.org/attachment.cgi?id=156545 (after
enabling the pref, of course).
So it seems the only real justification for defaulting the pref to "off" is that
scripting the status bar text "is an irritating feature which is mostly used for
evil". But that could be said about animated gifs and Flash as well. We should
give the user options to disable these things - but disabling them by default
is, IMO, wrong.
Notice that there are bugs filed on this (bug 256204, bug 294147). People are
expecting window.status() to work by default, and I think they are right.
I'm bringing this up here to grab the atention of people involved in the
original decision, and because this is where the original discussion took place.
I hope this is not considered spamming. I'll be happy to continue the
discussion somewhere else.
Assignee | ||
Comment 25•20 years ago
|
||
(In reply to comment #24)
> Excuse me for bringing this bug back from the dead, but I really don't see how
> disabling "allow scripts to change the status bar text" has anything to do with
> security (which was the motive behind this bug).
Because "the status bar is trusted" is much, much easier to explain to a user
than "Well, you can trust the right-hand part, but you can't trust the left-hand
part. You see that little divider there? The one that's two pixels wide? No, not
that one, the one further to the left. Yes. That's the trust boundary."
Gerv
Comment 26•20 years ago
|
||
>
> Because "the status bar is trusted" is much, much easier to explain to a user
> than "Well, you can trust the right-hand part, but you can't trust the left-hand
> part. You see that little divider there? The one that's two pixels wide? No, not
> that one, the one further to the left. Yes. That's the trust boundary."
>
> Gerv
>
No need for sarcasm, Gerv. I can see your point, although "you can trust the
domain name next to the little lock icon" seems simple enough to me. If it
isn't, I would suggest somehow graphically associating the domain name with the
lock (e.g. putting them together on a yellow background). Using a bold font for
the domain name might also help.
Anyway, the silent majority here seems to agree with you, so I think I'll drop
the issue now and stop spamming the bug.
Assignee | ||
Comment 27•20 years ago
|
||
I apologise if that sounded sarcastic - it wasn't meant to be. It was just a
demonstration of a usability point.
Gerv
You need to log in
before you can comment on or make changes to this bug.
Description
•