Closed
Bug 27849
Opened 26 years ago
Closed 20 years ago
cursor does not change when attribute set on window
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: hangas, Assigned: dbaron)
References
Details
Attachments
(2 files)
Adding this line top global.css:
window[wait-cursor] { cursor: wait !important; }
and this function to globalOverlay.js:
function goWaitCursor(wait)
{
if ( wait )
top.window.document.documentElement.setAttribute("wait-cursor", "true");
else
top.window.document.documentElement.removeAttribute("wait-cursor");
}
and then calling goWaitCursor(true); does not cause the cursor to change to a
wait cursor. Setting the cursor-wait attribute on the window tag in the xul file
does change the cursor, but this needs to be controlled from JS.
|
||
Comment 1•26 years ago
|
||
YOu should be saying "top.document" not "top.window.document".
Assignee: trudelle → hangas
Tried that too. top.document.documentElement.setAttribute("wait-cursor",
"true"); Both ways set the attribute on the window tag, but neither one changes
the cursor.
Assignee: hangas → hyatt
Hmmm. Today's build showing wait cursor in toolbar but not in other areas of
window. Going back for more investigation.
Assignee: hyatt → hangas
This is seriously broken. All of today's investigation points back to the fact
that this does not work. Will find Hyatt to demonstrate problem and determine
solution.
|
|
||
Comment 5•26 years ago
|
||
Looks like CSS doesn't dynamically recompute cursors when the DOM changes an
attribute that results in a cursor change.
Assignee: hangas → pierre
|
|
||
Comment 6•26 years ago
|
||
Assigning to Waqar: 1/3 of Pierre's NEW bugs to help reduce his doomage factor
Assignee: pierre → waqar
|
|
||
Comment 7•26 years ago
|
||
Reassigned back to me these bugs that shouldn't have left my list.
Assignee: waqar → pierre
|
|
||
Comment 8•26 years ago
|
||
*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
jrgm@netscape.com
QA Contact: paulmac → jrgm
|
|
||
Updated•26 years ago
|
Severity: normal → blocker
|
|
||
Comment 9•26 years ago
|
||
This bug is blocking MailNews from changing the cursor when we NEED to give UI
feedback to the user. Marking blocker.
|
|
||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M18
|
|
||
Comment 10•25 years ago
|
||
Just ran into this while looking for info on another closed bug 9668. That was
a bug about adding xp cursor support. It seems like that info might be
pertinent to this bug so I thought I'd commment this one.
|
|
||
Comment 12•25 years ago
|
||
|
|
||
Comment 13•25 years ago
|
||
Hyatt's comment:
"Looks like CSS doesn't dynamically recompute cursors when the DOM changes an
attribute that results in a cursor change."
is reflected in the attached testcase where you use the DOM to remove a HREF
from an anchor. The cursor still changes to a hand when it is moved over an
anchor with no HREF and the link border still shows. Also the link underlining
persists when the HREF is removed on text.
This gives users incorrect UI feedback - as actually clicking on the
linkless links doesn't do anything.
|
|
||
Comment 14•24 years ago
|
||
Changing from "blocker" to "normal" and moving to m0.9.3.
Severity: blocker → normal
Target Milestone: mozilla0.9.1 → mozilla0.9.3
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.6 → mozilla1.0
|
|
||
Updated•24 years ago
|
Target Milestone: mozilla1.0 → mozilla1.1
|
|
||
Comment 15•24 years ago
|
||
Bulk moving from Moz1.1 to future-P1. I will pull from this list when scheduling
work post Mozilla1.0.
Priority: P3 → P1
Target Milestone: mozilla1.1 → Future
|
Assignee | |
Comment 16•23 years ago
|
||
Assigning pierre's remaining Style System-related bugs to myself.
Assignee: pierre → dbaron
Status: ASSIGNED → NEW
Priority: P1 → P3
|
|
||
Comment 17•22 years ago
|
||
Stills seeing this problem with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031105
Firebird/0.7+
comment 5 seems to nail the problem down. Surprisingly this bug also exists in
IE. Is anyone still working on this?
|
||
Comment 18•21 years ago
|
||
I guess this bug also covers this testcase.
It consists of the following code:
<html>
<head>
<style>
a:focus{cursor:crosshair;}
</style>
</head>
<body>
<a href="#">When you click with the mouse on this link, the cursor should
change to a crosshair instantly</a>
</body>
</html>
|
|
Assignee | |
Comment 19•20 years ago
|
||
Didn't biesi fix this in bug 263671?
|
|
||
Comment 20•20 years ago
|
||
Indeed, it seems fixed to me. The testcases are WFM with current trunk build.
|
||
Comment 21•20 years ago
|
||
yeah, fixed by that bug... I wasn't aware of this one
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•