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.

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

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?

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

Comment on attachment 155421 [details] [diff] [review] Workaround Why is this a workaround? I don't really know about this stuff. Maybe bryner?

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

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 on attachment 155421 [details] [diff] [review] Workaround OK, r+sr=bzbarsky if you add a nice XXX comment explaining why you're doing this....

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

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.

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 ...

(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.

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

(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...

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

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

I think this is fixed nowadays, right?