Closed
Bug 31997
Opened 24 years ago
Closed 24 years ago
Statusbar text set via JavaScript persists over session
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: caseyperkins, Assigned: jst)
References
()
Details
(Keywords: testcase, Whiteboard: [nsbeta2-][nsbeta3+])
Attachments
(1 file)
111 bytes,
text/html
|
Details |
Status bar messages set by window.defaultStatus carry over to other, non-related pages. Try visiting www.people.memphis.edu/~trainlib/documentation, hover the mouse over the page, then go to www.yahoo.com. The status bar message set by window.defaultStatus remains.
Comment 1•24 years ago
|
||
Reassign to DOM 0.
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
QA Contact: rginda → desale
Reporter | ||
Comment 3•24 years ago
|
||
I checked this bug again with a recent build and found that now, the text generated by window.defaultStatus doesn't display at all!
Updated•24 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 6•24 years ago
|
||
Travis, I think this is due to your webshell API changes, could you have a look?
Assignee: jst → travis
Actually, this is due to the fact that I changed navigator to properly show the default message when it's set. The problem is the dom window code isn't clearing out the default message on the change to a new location. Flipping back to jst to make the dom window code properly set the default message to null upon changing pages.
Assignee: travis → jst
One comment on this problem. It seems to happen when you set window.content.status="something". What seems to be happening is that window.content.status never gets reset to the empty string. Okay, you already know this, but I have some other stuff to add: The situation is further exacerbated by the fact that in the XUL, jsStatus is the first thing checked by the function UpdateStatusField. What you can do to work around it is to modify the function nsXULBrowserWindow.setDefaultStatus so that it resets the value of jsStatus; ie: insert the line jsStatus=null; right before the call to UpdateStatusField() I'm not saying that this is the place to fix the problem, but it does the trick. Andrew.
Assignee | ||
Comment 10•24 years ago
|
||
Hardly a beta stopper, M18.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 11•24 years ago
|
||
*** Bug 40638 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
*** Bug 40295 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
*** Bug 41326 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 14•24 years ago
|
||
*** Bug 37550 has been marked as a duplicate of this bug. ***
Comment 15•24 years ago
|
||
*** Bug 42062 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
*** Bug 31138 has been marked as a duplicate of this bug. ***
The dups of this bug seem to vary a bit -- this may (but may not) be multiple bugs. However, it's quite annoying (and wrong) to have the status bar carry over to other pages. (Could it be seen as a security problem too??) Thus, nominating nsbeta3.
Keywords: nsbeta3
Comment 18•24 years ago
|
||
adding mostfreq keyword. this would be nice to have in nsbeta2 though...
Keywords: mostfreq
Comment 19•24 years ago
|
||
*** Bug 42908 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
I would like to nominate this as nsbeta2 and see what pdt has to say about it. The doubleclicks of the world are going to have a field-day when they discover this bug -- we will be giving them free persistent billboard space for their ads. See my comments in dup bug 42908.
Keywords: nsbeta2
Comment 21•24 years ago
|
||
Marking nsbeta2-. The adverse effects from this are minimal, though we should fix this in beta 3. It is already nominated as such.
Whiteboard: [nsbeta2-]
Comment 22•24 years ago
|
||
*** Bug 43165 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•24 years ago
|
||
*** Bug 43139 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
This could be a security problem...sort of acts like a session cookie, allows information to persist as the user visits different pages. Let's please get this fixed by beta3.
Comment 25•24 years ago
|
||
*** Bug 38381 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
*** Bug 43140 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
*** Bug 44747 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
*** Bug 45548 has been marked as a duplicate of this bug. ***
Comment 29•24 years ago
|
||
*** Bug 45780 has been marked as a duplicate of this bug. ***
Comment 30•24 years ago
|
||
clarifying summary a little. also, this is XP...
OS: Windows 95 → All
Hardware: PC → All
Summary: window.defaultStatus message carries over to other pages → Statusbar text set by JavaScript persists throughout session
Retitling again, since new title was too general. This is only text set via window.defaultStatus, not window.status.
Summary: Statusbar text set by JavaScript persists throughout session → Statusbar text set as defaultStatus persists over session
Comment 32•24 years ago
|
||
No, I don't think so. See some of the dups of this bug that mention document.status and window.status being affected as well: 43140, 42908, 37550, 40295, 40638, and 35602. See even aagno@cs.toronto.edu's 5/2 comment in this bug that suggests that window.content.status is also affected.
Summary: Statusbar text set as defaultStatus persists over session → Statusbar text set via JavaScript persists over session
Comment 33•24 years ago
|
||
Comment 34•24 years ago
|
||
*** Bug 46600 has been marked as a duplicate of this bug. ***
Comment 35•24 years ago
|
||
*** Bug 46945 has been marked as a duplicate of this bug. ***
Comment 36•24 years ago
|
||
*** Bug 47450 has been marked as a duplicate of this bug. ***
Comment 38•24 years ago
|
||
*** Bug 48317 has been marked as a duplicate of this bug. ***
Comment 39•24 years ago
|
||
*** Bug 48596 has been marked as a duplicate of this bug. ***
Comment 40•24 years ago
|
||
*** Bug 49136 has been marked as a duplicate of this bug. ***
Comment 41•24 years ago
|
||
*** Bug 49469 has been marked as a duplicate of this bug. ***
Comment 42•24 years ago
|
||
*** Bug 49538 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•24 years ago
|
Priority: P3 → P1
Comment 43•24 years ago
|
||
*** Bug 50110 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 44•24 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 45•24 years ago
|
||
*** Bug 50735 has been marked as a duplicate of this bug. ***
Comment 46•24 years ago
|
||
*** Bug 50902 has been marked as a duplicate of this bug. ***
Comment 47•24 years ago
|
||
Linux 2000090208 The persistence of Statusbar text is fixed ONLY when the page is changed/reloaded. In this bug report there is also another issue, see bug 48317 (duped to this one). The persistence of status-bar messages is still here when the page is not changed/reloaded, for ex. in onmouseover="window.status=... See testcase reported from bug 48317: http://www.ugcs.caltech.edu/~iraqispy/test.html Which bug have I to reopen?
You need to log in
before you can comment on or make changes to this bug.
Description
•