Closed Bug 286388 Opened 17 years ago Closed 17 years ago

cursor:url() overwrites child elements cursor value (cascade doesn't work)

Categories

(Core :: CSS Parsing and Computation, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8beta2

People

(Reporter: Peter6, Assigned: dbaron)

References

Details

(Keywords: testcase, Whiteboard: [patch])

Attachments

(3 files, 1 obsolete file)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050315
Firefox/1.0+

I know the summary is wrong but I don't know the proper wording.

repro:
1.Open testcase
2.Case 1 shows normal behaviour, the cursor in the red box is pointer, in the
green box is wait
3.Case 2 shows wrong behaviour, the cursor in the red box is url(),pointer , in
the green box should be wait but url(),pointer is displayed

expected:
the cursor url() to behave the same as default cursors

( bug 38447 cursor:url() implementation )

testcase follows
Attached image cursor for testcase
Attached file testcase
Keywords: regression, testcase
Keywords: regression
Summary: cursor:url() breaks CSS rule → cursor:url() overwrites child elements cursor value (cascade doesn't work)
This should probably be marked as a regression, otherwise I think (contrary to
your suggestion on the forum) that your summary is ok. 

Just in case anyone missed it though... cursor:url() properties are being
inherited by child elements, even if they have an overriding value set. This
should not be the case.
(In reply to comment #3)
> This should probably be marked as a regression

why? this never worked correctly.
Attached patch patch (untested) (obsolete) — Splinter Review
This will probably fix it, but the url() support doesn't work for me (GTK2), at
least based on the testcase in this bug, so I can't tell for sure.  Could
somebody test?
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [patch]
Target Milestone: --- → mozilla1.8beta2
yep, the patch does seem to work.

it seems this line, a bit down, can be removed then:
       if (ui->mCursorArray.Count() == 0) {
Attached patch patchSplinter Review
Attachment #177676 - Attachment is obsolete: true
Attachment #177684 - Flags: superreview?(bzbarsky)
Attachment #177684 - Flags: review?(bzbarsky)
I was suspicious of that code when I reviewed it, and I should have thought
about it more carefully.  It's also completely broken in the non-null aStartData
with 'inherit' case.
sorry about this bug :( thanks for fixing it!
OS: Windows 2000 → All
Hardware: PC → All
Blocks: zoompan
I hereby request for blocking-aviary1.1 and blocking1.8b2 flags, the fix seems
important.
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Comment on attachment 177684 [details] [diff] [review]
patch

r+sr=bzbarsky
Attachment #177684 - Flags: superreview?(bzbarsky)
Attachment #177684 - Flags: superreview+
Attachment #177684 - Flags: review?(bzbarsky)
Attachment #177684 - Flags: review+
Fix checked in to trunk, 2005-03-16 20:38 -0800.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?
Resolution: --- → FIXED
FWIW, it's not working for me because I hit this early return in
widget/src/gtk2/nsWindow.cpp's SetCursor(imgIContainer*):

    nsCOMPtr<nsIGdkPixbufImage> pixImg(do_GetInterface(frame));
    if (!pixImg)
        return NS_ERROR_NOT_AVAILABLE;
Please respond to that comment in bug 38447 rather than here.
->verified

thanks for the quick fix
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.