Open Bug 1603699 Opened 5 years ago Updated 1 month ago

Enable DefaultURI use for unknown schemes

Categories

(Core :: Networking, task, P3)

task

Tracking

()

ASSIGNED
122 Branch
Tracking Status
relnote-firefox --- 122+
firefox122 --- fixed

People

(Reporter: valentin, Assigned: edgul)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

(Keywords: dev-doc-complete, Whiteboard: [necko-triaged])

Attachments

(2 files, 1 obsolete file)

Steps:

  • [ ] Merge https://github.com/servo/rust-url/pull/537
  • [ ] Update rust-url in Gecko
  • [ ] Flip the network.url.useDefaultURI pref
  • [ ] Fix expected-fail WPT tests
  • [ ] Restrict origins to schemes allowed by the URL spec + the ones we add to the allow list (bug 1553105)

Rust URL isn't perfectly ready yet for use, and I don't have the cycles to fix it right now. Unassigning for now.

Assignee: valentin.gosu → nobody
Priority: P2 → P3
Severity: normal → S3
Blocks: 1374505
Depends on: 1633289
Depends on: 1553105
Assignee: nobody → edgul
Depends on: 1853723

Depends on D186796

Attachment #9349618 - Attachment is obsolete: true
Blocks: 1863622
Blocks: 1326394
Depends on: 1866135
See Also: → 1868413

The expectation for SetPathQueryRef for URLs that cannot be a base is
that they will replace everything after the scheme.
Since the url crate doesn't have a method similar to SetPathQueryRef
we need to special case this in DefaultURI.

Pushed by eguloien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7f3c08da2ac9
Fix DefaultURI::Mutator::SetPathQueryRef for URLs that cannot be a base r=edgul
https://hg.mozilla.org/integration/autoland/rev/f8a1e1d313cc
Enable default URI pref. r=valentin,necko-reviewers,extension-reviewers,robwu
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 122 Branch

We might want to consider doing a release note for this?

Flags: needinfo?(edgul)
Keywords: dev-doc-needed

Can you point me in the right direction?

Flags: needinfo?(edgul) → needinfo?(evilpies)

Drive by comment - the Release Note Process info should outline how to add a release note nomination on this bug. You provide some wording and release management will take it from there.

Thanks Donal.

Flags: needinfo?(evilpies)

Release Note Request
[Why is this notable]: This change alters the fallback URL parser to one that is more comprehensive. As a result of this change we are now passing hundreds more web platform tests which ultimately improves our spec adherence and web compatibility.
[Affects Firefox for Android]: Yes
[Suggested wording]: Changed our fallback URL parser for unknown schemes to DefaultURI for improved spec adherence and web compatibility

relnote-firefox: --- → ?

Thanks, added to the Fx122 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx122 release notes

FF122 MDN docs for this can be tracked in https://github.com/mdn/content/issues/31100

But what is the direct impact of this change to website-developers? What should they do differently because of this?
I think the answer is nothing, and that this does not require MDN documentation right?

If not, can you explain what documents we might need to touch?

Flags: needinfo?(edgul)

This shouldn't affect mdn content. Thanks.

Flags: needinfo?(edgul)

Thank you

FYI, and I don't know who can update it, this means that the docs in https://firefox-source-docs.mozilla.org/networking/url_parsers.html for DefaultURI are out of date.

Thanks for pointing that out.
I'll make sure to update the docs.

See Also: → 1569733
Duplicate of this bug: 1700078
Regressions: 1876731
Regressions: 1876729
Regressions: 1876491

I have strong doubts about the web compatibility of this change considering the number of regression.

Regressions: 1876952
Regressions: 1876906

(In reply to Tom S [:evilpie] from comment #19)

I have strong doubts about the web compatibility of this change considering the number of regression.

These issues would have been visible to people using safari, but Chrome hasn't shipped this change yet.
I assume we could have a list of protocols that we exclude from regular URL parsing.
The ed2k protocol seems like the best candidate for that, as even their wikipedia article explaining the URI format has this bad scheme: https://en.wikipedia.org/wiki/Ed2k_URI_scheme#File_link_format

I suppose we could also ship a webcompat intervention to fix specific links on specific sites, but I don't think that's possible for all broken protocols.

Ultimately the legacy protocol list is probably the best option. Thoughts?

I opened an issue in the WhatWG URL repository: https://github.com/whatwg/url/issues/815

Regressions: 1877012
See Also: → 1877753
Regressions: 1877573
No longer regressions: 1877573
See Also: → 1876274
Regressions: 1876274
See Also: 1876274
Depends on: 1877753
Depends on: 1878001
See Also: → 1878295
Regressions: 1878295
See Also: 1878295
Regressions: 1877753
See Also: 1877753
See Also: → 1878724

We disabled this in bug 1877753.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Depends on: 1889988
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: