251197 - Anonymous scrollbar in document exposed to dom when attaching mouse event listener.

Status: RESOLVED WORKSFORME

(Core :: DOM: Events, defect)

Description

[Martijn Wargers (dead)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040711 Firefox/0.9.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040711 Firefox/0.9.0+

See upcoming testcase.
The scrollbar should not become green when you mouseover it. 
Also you should not see the nodename of the scrollbar in the statusbar.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 2

[[e-mail]]

I thought that anonymous content was supposed to be protected by caps...

Comment 3

[Martijn Wargers (dead)]

It seems like this is a regression:
It does not happen in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/2004-01-29
Firebird/0.8.0+
It does happen in:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/2004-01-30
Firebird/0.8.0+

Maybe this is a regression from fixing bug 196755?

Comment 4

[[e-mail]]

Scrollbars are supposed to be native anonymous, so the events should get
retargetted at around line 2698 of nsXULElement.cpp, no?

Comment 5

[[e-mail]]

Attachment: Workaround

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 155421 [details] [diff] [review]
Workaround

Why is this a workaround?

I don't really know about this stuff. Maybe bryner?

Comment 7

[Boris Zbarsky [:bzbarsky]]

So the only place <scrollbar> elements are used is as native anonymous content?

Comment 8

[[e-mail]]

This change would only affect listeners to events captured or bubbled up from
scrollbars. However my search of the tree turned up no such listeners.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 155421 [details] [diff] [review]
Workaround

OK, r+sr=bzbarsky if you add a nice XXX comment explaining why you're doing
this....

Comment 10

[[e-mail]]

Workaround checked in. Bug 165110 left open for the correct fix.

Comment 11

[[e-mail]]

We have a conflict of interest here.
When using the Modern theme on the mac, the anonymous scrollbars are protected
by caps from showing the OS look and feel, and instead each scrollbar logs a JS
exception. Futhermode, explicit scrollbars such as the one using by the tree are
also protected by caps so that they do not work in content.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: Testcase using .originalTarget

The bug is still there when using .originalTarget.
Perhaps we could add some attribute to XBL which defines whether the
binding should be handled as 'native' and then the .originalTarget
could be the same as .target ...

Comment 13

[[e-mail]]

(In reply to comment #12)
>The bug is still there when using .originalTarget.
You don't see the bug for the input because we protect the DIV using CAPS.
We aren't able to protect the scrollbar using CAPS because of its XBL.
I don't know if updating the original target will break C++ event listeners.

Comment 14

[[e-mail]]

Attachment: Untested patch

Well, it fixes the testcase, but I didn't look for regressions.

Comment 15

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #12)
> Perhaps we could add some attribute to XBL which defines whether the
> binding should be handled as 'native' and then the .originalTarget
> could be the same as .target ...

Or we could simply nuke the originalTarget when retargeting from native anonymous content; I believe we have bugs on doing that already...

Comment 16

[Martijn Wargers (dead)]

*** Bug 331057 has been marked as a duplicate of this bug. ***

Comment 17

[Jesse Ruderman]

Bug 401549 describes another way these scrollbar elements can leak out to web page scripts.

Comment 18

[Martijn Wargers (dead)]

I think this is fixed nowadays, right?