Should the order of registrations returned by getRegistrations() be sorted by scope?

[makotoshimazu]

This question is raised when I tried to fix a flaky test in Chromium.

Currently we use an ordered map for scope to registration map but don't use the sort operation before iterating over the map (step 3.2 in the spec of getRegistrations()). This means that the order of the scope to registration map is FIFO.
Should we change it to sort the registration map before iteration, or is FIFO better in this case?
Do you have any thoughts?

[mfalken]

FWIW I think we could make Chromium match the current spec by sorting by registration id.

Do other browsers preserve the FIFO order? If so, maybe we should just change Chromium to do so and call it a day. @youennf @asutherland

[asutherland]

Per https://searchfox.org/mozilla-central/rev/9415ecf29ba1acbef9381335e0ecde5916ca4073/dom/serviceworkers/ServiceWorkerManager.cpp#1678 we (Firefox/Gecko) apparently order such that:

    // Sort by length, with longest match first.
    // /foo/bar should be before /foo/
    // Similarly /foo/b is between the two.

This is an outgrowth of #287 deciding on longest prefix match now codified in https://w3c.github.io/ServiceWorker/#scope-match-algorithm. We store things as an ordered list, and we order the list so that if we traverse the list in order, we will naturally find the longest prefix first.

This seems better than FIFO order to me and most consistent with the rest of the spec implementation.

[mfalken]

Thanks @asutherland. What order does getRegistrations() return when the scopes are "foo" and "bar"?

[youennf]

WebKit implementation is sorting by insertion order.

[asutherland]

I think it's insertion-order dependent in that case, which makes it undesirable after all.

For sanity of tests, I think the current spec of ordering based on the serialized scope is perhaps best. Actual insertion order depends on invocation of Set Registration invoked from inside Register which happens from inside the per-scope job queue which is triggered in parallel from Run Job queuing a task on an unnamed task source.

[makotoshimazu]

So if we do that, will the order be a kind of lexicographical order but longer scopes will be earlier?

For example:

bar/abc
bar/abd
bar/ac
ba/
b
foo/

Now I'm feeling that simple lexicographical order might be simpler. What do you think?

[wangw-1991]

In chromium, the registrations returned by getRegistrations() are composed of two parts (the corresponding code): stored registrations and unstored registrations. These two parts are inserted into the same vector and then return the vector.
I think before return the vector, we can sort it by registration.scope using simple lexicographical order. Is it OK?

[wangw-1991]

What's your opinion? @mattto

[mfalken]

To summarize the current situation:

1. Spec: insertion order
2. Firefox: Sort by length first, with insertion-order to break ties
3. WebKit: insertion order
4. Chrome: no intended order

I'm leaning toward insertion order as the one with least changes. For the tests that actually test the order, we'd have to make sure to set up the test correctly, as @asutherland mentions there are parallel tasks on unspecified task sources.

But I don't feel strongly. cc @jakearchibald @jungkees

[wanderview]

A minor note: If my scopes pattern proposal moves forward then insertion order might work a little bit better. Of course, we can always define some sort order for the patterns and list-of-patterns but that may not be intuitive for developers.

[jungkees]

Insertion order sounds good to me if @asutherland is fine with that. I don't think we had any other intention except letting it be an ordered map for the level of compat we get from it. @mattto's comment on the test would be important, if we go with this decision.

[asutherland]

Insertion order works for me.

[mfalken]

Thanks everyone. It seems we have consensus to keep the current spec which requires insertion order.