1783497 - chrome:// URL-addresses are treated as invalid URL-addresses by input[type=url] elements

Status: VERIFIED FIXED

(Core :: DOM: Forms, defect)

Description

[importu]

Attachment: Screenshot.png

Steps to reproduce:

1. Go to https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/url
   There's a small demo form in the "Making a URL required" section.
2. Enter "chrome://bookmarks" or any other "chrome://" address into the input field.
3. Click "Submit"

Actual results:

Firefox shows the "Please enter a URL" error.
Other browsers submit the form.

Expected results:

The "input[type=url]" is not an "a[href]" link element and shouldn't filter out "chrome://" links as they might just go into a site's database for displaying purposes (or for a thousand other different reasons) and not into a link address on a webpage.

This is a Firefox-only non-standard behavior/bug/oversight that shouldn't happen.

Comment 1

[Dennis Schubert [:denschub]]

This is not a WebCompat issue. I'm moving it back.

Comment 2

[importu]

(In reply to Dennis Schubert [:denschub] from comment #1)

This is not a WebCompat issue. I'm moving it back.

Well,

https://bugzilla.mozilla.org/describecomponents.cgi?product=Web%20Compatibility
Web Compatibility
A place to move bugs for sites or content that does not work in Firefox, but works in other browsers.

https://bugzilla.mozilla.org/show_bug.cgi?id=1783497
Firefox shows the "Please enter a URL" error.
Other browsers submit the form.

but I don't mind either way.

This issue was previously confirmed on WebCompat on github:
https://github.com/webcompat/web-bugs/issues/108379

Don't know why you removed the Firefox version though.

Comment 3

[importu]

Attachment: Example.html

Attached an example .html file with 4 identical forms with pre-filled URL-addresses.

The inputs with addresses the browser considers invalid will be highlighted red.

If the form submits, it will show "Form submitted" alert message.

In Chrome all 4 forms submit correctly.

In Firefox only the last 3 submit correctly, and the first one highlights red and shows "Please enter a URL" error bubble and prevents form submission.

Comment 4

[Sean Feng [:sefeng211]]

I can take a look.

Comment 5

[Hani Yacoub, Desktop QA]

Managed to reproduce the issue on Window 10 x64, macOS 11.6 and on Ubuntu 20.04 x64.

Comment 6

[Sean Feng [:sefeng211]]

So our code don't think chrome:://bookmarks as a valid url, specifically it fails at when we try to canonify it. If you pass something like chrome://bookmarks/1/1 things work, so this seems to be bug.

I also check the spec, I think we are looking for valid absolute url here. I think chrome:://bookmarks falls under a URL-scheme string that is not an ASCII case-insensitive match for a special scheme, followed by U+003A (:) and a relative-URL string. So It should work I think.

Is this something we are aware Olli?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I don't think we should throw if canonify fails. Given https://searchfox.org/mozilla-central/rev/fa81b64fc1a339e2b2b1f6a8637a689916e13c4e/dom/html/input/SingleLineTextInputTypes.cpp#112-113 I think that would be enough to fix this.

(chrome: protocol itself is of course very much browser internal thing and shouldn't be exposed to the web, but I guess a web page may still use it for its own purposes.)

Comment 8

[Sean Feng [:sefeng211]]

Attachment: Bug 1783497 - Don't throw if chrome URL canonicalization fails r=smaug

Looks like this is not needed and making a web-compat issue.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/09fd858a96c9
Don't throw if chrome URL canonicalization fails r=smaug

Comment 10

[Cristina Cozmuta (:CrissCozmuta)]

Backed out for causing Xpcshell failures on test_ext_cookies_partitionKey.js
Backout link
Push with failures
Link to failure log
Failure line :
TEST-UNEXPECTED-FAIL | xpcshell.ini:toolkit/components/extensions/test/xpcshell/test_ext_cookies_partitionKey.js | xpcshell return code: 0

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:sefeng, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Up to sefeng to deal with.

Comment 13

[Sean Feng [:sefeng211]]

Attachment: Bug 1783497 - Make GetPartitionKeyFromURL fails early for chrome url r=smaug

It looks like we don't want to get partition keys from
chrome urls.

Depends on D156985

Comment 14

[Sean Feng [:sefeng211]]

I have 2 needinfos, so removing one of them.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4da944d66d96
Don't throw if chrome URL canonicalization fails r=smaug
https://hg.mozilla.org/integration/autoland/rev/0200c81aa87f
Make GetPartitionKeyFromURL fails early for chrome url r=smaug,robwu

Comment 16

[Noemi Erli[:noemi_erli]]

Backed out 2 changesets (Bug 1783497) for causing failures in test_displayOrigin.js CLOSED TREE

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=XN56z5kXRLaAlLWBfL1T2w.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=linux%2C18.04%2Cx64%2Cwebrender%2Copt%2Cxpcshell%2Ctests%2Ctest-linux1804-64-qr%2Fopt-xpcshell%2Cx3&revision=0200c81aa87f9a0bbaa6a2282ea28a0d3937bbad

Logs:
xpc: https://treeherder.mozilla.org/logviewer?job_id=393453862&repo=autoland&lineNumber=3696
wpt: https://treeherder.mozilla.org/logviewer?job_id=393453690&repo=autoland&lineNumber=3730
mochitest: https://treeherder.mozilla.org/logviewer?job_id=393453776&repo=autoland&lineNumber=4491

Backout: https://hg.mozilla.org/integration/autoland/rev/02ddcb6d4818c53195395e697ce428244507ab97

Comment 17

[Sean Feng [:sefeng211]]

Attachment: Bug 1783497 - Update LoginInfo related tests in passwordmgr for recent chrome url changes r=smaug,sfoster!

These tests expect Service.io.newURI raises exception when the given
urls are chrome urls. Since we no longer raise exception for
chrome url canonicalization failures, the tests need to be updated.
Plus, this should be fine because even without the canonicalization changes,
using a chrome url like "chrome://path/path/path" would raise exception too.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/36d1dfe3d6c9
Don't throw if chrome URL canonicalization fails r=smaug
https://hg.mozilla.org/integration/autoland/rev/c92b392a186f
Make GetPartitionKeyFromURL fails early for chrome url r=smaug,robwu
https://hg.mozilla.org/integration/autoland/rev/0a2510ef7585
Update LoginInfo related tests in passwordmgr for recent chrome url changes r=smaug,sfoster,credential-management-reviewers,sgalich

Comment 19

[Narcis Beleuzu [:NarcisB]]

Backed out for wpt failure on protocol.https.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/600032b9fdfb80c454589aca6a39a292ad075618
Log link: https://treeherder.mozilla.org/logviewer?job_id=393684006&repo=autoland&lineNumber=6046

Comment 20

[Narcis Beleuzu [:NarcisB]]

Please also check https://treeherder.mozilla.org/logviewer?job_id=393684220&repo=autoland&lineNumber=5098

Comment 21

[Sean Feng [:sefeng211]]

Attachment: Bug 1783497 - Update test_url_data.html r=smaug

Due to the changes to chrome url canonicalization, we need to update
URL::SetProtocol to make it fail when the given url is a chrome url.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d9f642210f97
Don't throw if chrome URL canonicalization fails r=smaug
https://hg.mozilla.org/integration/autoland/rev/d3df1cd24b2d
Make GetPartitionKeyFromURL fails early for chrome url r=smaug,robwu
https://hg.mozilla.org/integration/autoland/rev/07cac19d7ebe
Update LoginInfo related tests in passwordmgr for recent chrome url changes r=smaug,sfoster,credential-management-reviewers,sgalich
https://hg.mozilla.org/integration/autoland/rev/5e1071802aad
Update test_url_data.html r=smaug

Comment 23

[Sean Feng [:sefeng211]]

Removing my NI and hope it'll stick.

Comment 24

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/d9f642210f97
https://hg.mozilla.org/mozilla-central/rev/d3df1cd24b2d
https://hg.mozilla.org/mozilla-central/rev/07cac19d7ebe
https://hg.mozilla.org/mozilla-central/rev/5e1071802aad

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:sefeng, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Comment 27

[Sean Feng [:sefeng211]]

This is not an urgent thing, so no need for uplift.

Comment 28

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2022-08-06 Nightly build on macOS 12. Verified as fixed on Firefox 108.0b2(build ID: 20221115200658) and Nightly 109.0a1(build ID: 20221116182402) on macOS 12, Windows 10, Ubuntu 22.