Fork Toolkit autocomplete controller

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
5 years ago
5 years ago

People

(Reporter: Unfocused, Assigned: Unfocused)

Tracking

(Blocks 1 bug)

unspecified
Points:
8
Dependency tree / graph
Bug Flags:
firefox-backlog +
qe-verify +

Firefox Tracking Flags

(Not tracked)

Details

For some things we want to do/fix in autocomplete for the URL bar, the only way is to change the autocomplete controller behaviour and/or the API. Unfortunately, this ends up affecting every other consumer. Due to some fragility around autocomplete, this will result in too many regressions.

As a solution to that, we can fork the Toolkit autocomplete controller - using a modified version just for Firefox's URL bar. This would allow us to change the behaviour/API of without affecting other code, and ship changes on a much shorter timescale.

Arguably, the controller needs significant rework, or potentially a rewrite. This initial fork can be seen as either an initial step ion achieving that, or as a stopgap to allow us time to make more significant changes (depending on what is decided).
Flags: qe-verify+
Flags: firefox-backlog+
why not forking it into toolkit?
Paolo has already sort of a plan for this, but it's not something that could be done before bug 951624...

mostly cause we need bug 951624 asap, like tomorrow.

Comment 2

5 years ago
Actually, forking might result in us resolving bug 951624 sooner. I believe this is what Blair is trying to understand at the moment. We talked a little bit and I shared the outcome of our work week discussion with him, the next steps are for him to figure out a more detailed plan, since he has worked on the code and knows what the actual pain points are. When that is ready we'll need to discuss our options together.

As we discussed at the work week, forking into Firefox or Toolkit would make little difference for the initial stages, though Toolkit might be slightly better in preparation for reusing in more places than the URL bar.
Forking into Firefox because then we can guarantee no one else is going to use it while it's in flux, so we have the absolute minimum chance of regressions (ie, limited to the urlbar) and move faster. I figure if we can get it stable and usable for other things, then we can move the new code to Toolkit. We did the same with rewriting the toolbar customization code.

And yea, I think this is needed to fix bug 1054914, which we need to ship bug 951624. This lets me do that *much* quicker.

Taking this now, because I'm just doing a quick fork now to be able to work on bug 1054914.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Flags: needinfo?(mmucci)
OS: Windows 8.1 → All
Hardware: x86_64 → All
QA Contact: andrei.vaida
Flags: needinfo?(mmucci) → needinfo?(gavin.sharp)
Looks like this needs to go in Toolkit after all, due to awkwardness with internal/external string API mess.

And it also ended up being more complicated than I expected, as my initial approach was to clone all the existing IDL interfaces. Unfortunately, so many things tie into the existing interfaces.

What should work is keeping the existing interfaces, but introducing new interfaces that inherit from them. I had avoided this originally because it results in more complex code, and means we can't use the fork to remove features.

IMO, this ends up meaning that beyond the scope of small-ish bugs we want to fix in the short-term, a more significant monolithic rewrite becomes the more desirable approach.
Summary: Fork Toolkit autocomplete controller into Firefox → Fork Toolkit autocomplete controller
Component: Location Bar → Places
Product: Firefox → Toolkit
Version: 30 Branch → unspecified
could we do a build-time fork so that only one of the 2 is built, and build the new one just for Firefox? then we could remove unused features, I guess. We will just have to pay more attention to not break form history.

Btw, what you are saying is that it's not possible to make only the awesomebar use a totally different autocomplete component with different interface names? so copy toolkit/components/autocomplete to toolkit/components/autocomplete2, do the same with autocomplete.xml, rename all interfaces (and uuids), fix their internal references to interfaces, and make the urlbar point to the new binding?
Blocks: 1071461

Comment 6

5 years ago
(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #5)
> could we do a build-time fork so that only one of the 2 is built, and build
> the new one just for Firefox? then we could remove unused features, I guess.
> We will just have to pay more attention to not break form history.

This would not provide what we need, the point of the fork is to avoid concerns about breaking form history and search history. If we need to take care of compatibility with them, there is no need to fork at all.

> Btw, what you are saying is that it's not possible to make only the
> awesomebar use a totally different autocomplete component with different
> interface names? so copy toolkit/components/autocomplete to
> toolkit/components/autocomplete2, do the same with autocomplete.xml, rename
> all interfaces (and uuids), fix their internal references to interfaces, and
> make the urlbar point to the new binding?

This is the way to go if possible, and I don't think a build time switch is needed.
Flags: needinfo?(gavin.sharp)
Calling this WONTFIX, as per bug 1071344 (see especially bug 1071344 comment 5).
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.