Last Comment Bug 539357 - Move URL-bar specific code out of autocomplete.xml and into urlbarBindings.xml
: Move URL-bar specific code out of autocomplete.xml and into urlbarBindings.xml
Status: NEW
Product: Toolkit
Classification: Components
Component: XUL Widgets (show other bugs)
: unspecified
: All All
-- normal with 1 vote (vote)
: ---
Assigned To: Blair McBride [:Unfocused] (UNAVAILABLE)
: Neil Deakin
Depends on:
  Show dependency treegraph
Reported: 2010-01-12 17:15 PST by Blair McBride [:Unfocused] (UNAVAILABLE)
Modified: 2010-01-20 16:27 PST (History)
1 user (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Blair McBride [:Unfocused] (UNAVAILABLE) 2010-01-12 17:15:01 PST
Currently, the bindings in autocomplete.xml have code that is specific to the browser URL-bar. This is making debugging, maintaining, and changing things very difficult. URL-bar specific code should be moved to the relevant bindings in urlbarBindings.xml, which inherit from the bindings in autocomplete.xml
Comment 1 User image :Gavin Sharp [email:] 2010-01-14 09:49:39 PST
I'm assuming you're referring to most of the "autocomplete-richlistitem" binding? We should consider the compat cost of moving some of this code out of the toolkit, but I think we probably have a lot of leeway given that it's pretty UI-specific, as you mention. Fennec, for example, already redefines it's own custom autocomplete popup rather than using the default one.
Comment 2 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2010-01-20 16:27:17 PST
Yes, mostly the "autocomplete-richlistitem" binding. I think the gains outweigh the compat cost - especially given you usually have to completely override and re-implement certain methods just to change something. Hopefully separating out the urlbar-specific stuff will make that easier for the generic case (changing the normal autocomplete).

Note You need to log in before you can comment on or make changes to this bug.