'Applications' panel causes any richlistbox/richlistitem in a prefrences overlay to fire it's events




8 years ago
8 years ago


(Reporter: Bob Davies, Unassigned)


Firefox Tracking Flags

(Not tracked)




8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)

Including a richlistbox element in a preferences overlay causes it to fire the events associated with the 'Applications' page on change of the selected richlistitem.

If the Applications page has not been loaded (ie: the preferences opened to any other page), it throws an exception of:
Error: gApplicationsPane is not defined
Source File: chrome://browser/content/preferences/handlers.xml
Line: 97
If the Applications page HAS been activated, it instead throws:
Error: typeItem is null
Source File: chrome://browser/content/preferences/applications.js
Line: 1320

This occurs even when suppressonselect is true and/or when an explicit onselect attribute is attached to the richlistbox and/or when a class attribute is/is-not attached to the richlistbox.

I'm unable to determine definitively if it's actually the richlistitem(s) or the richlistbox which is affected. 
A look through the code around the lines where the error was thrown does not give me any indicators as to why it would be affecting richlistitems/boxes which are NOT the applications one (id="handlersView") as I can't find anything blindly adding event listeners to all richlistitems/boxes.

It doesn't appear to be causing a large overhead, as the failure-points seem to be early on in the execution of whatever method is attached, though I can't say this for sure.

There are also box model issues with richlistbox containing richlist items, the rows attribute is ignored, the richlistbox will always draw all contained rows without scrolling until it reaches it's container bounds (at which point it will scroll). If setting an explicit height style, the box will be that size, but the height of the contained richlistitems will determine the point at which following content starts to draw (causing scrolling errors within the prefpane. I'm guessing this could be partly bodged out with creative margin-ing).
I think these style issues may be related.

Reproducible: Always

Steps to Reproduce:
1. Create a preferences overlay containing a prefpane with at least one richlistbox within it.
2. Add multiple richlistitems, either in the xul, or from code.
3. View in preferences dialog and click (or key-nav) between the richlistitems.
4. Exceptions thrown
Actual Results:  
One of two unhandled exceptions called as described above.
gApplicationsPane is not defined
typeItem is null

Expected Results:  
UI behaviour is as expected, though the code throwing the exceptions should never have been executed.
You need to log in before you can comment on or make changes to this bug.