New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1803465 - extend isURLLenient to match IPv6 literals #4090
Conversation
I tested this using https://firefox-source-docs.mozilla.org/mobile/android/fenix.html and I'm not sure if the 3 workflow failures are my fault, nor how to rerun them. |
🚧 Commit message is using the wrong format: Fix [MaxLineLength] code style failure. The comment message should look like:
|
great, thank you for working on this 👍 edit: also there is no positive test for a full URL without a double colon, like this one: |
@Djfe this regex has no concept of a "misspelled" IP address. It's not looking at the address itself, just very broad character classes to distinguish possible URLs from garbage. |
Added more test cases. When I type these into the UI, it either shows "Invalid Address" or a completely blank tab, depending on the mood of the downstream URL parser. Note that both of these states are already reachable in Firefox 118:
|
🚧 Commit message is using the wrong format: Import translations from android-l10n The comment message should look like:
|
This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏 |
2288c33
to
bb2211f
Compare
Also known as Bug 1807752
This lets the "Fill link from clipboard" feature accept IPv6 literals like https://[2606:4700:4700::1111]
This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏 |
I'm still waiting for a reviewer. @csadilek perhaps? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi pmarks-net,
Thanks a lot for this PR and sorry for the late review.
While we were reviewing this, we tried to think of all the cases and here are some suggestions we came up with, that you can find in this patch file.
Please feel free to ask for clarifications is anything is not clear enough.
...omponents/support/utils/src/test/java/mozilla/components/support/utils/URLStringUtilsTest.kt
Outdated
Show resolved
Hide resolved
...omponents/support/utils/src/test/java/mozilla/components/support/utils/URLStringUtilsTest.kt
Outdated
Show resolved
Hide resolved
.../components/support/utils/src/test/java/mozilla/components/support/utils/WebURLFinderTest.kt
Show resolved
Hide resolved
...omponents/support/utils/src/test/java/mozilla/components/support/utils/URLStringUtilsTest.kt
Show resolved
Hide resolved
.../components/support/utils/src/test/java/mozilla/components/support/utils/WebURLFinderTest.kt
Outdated
Show resolved
Hide resolved
...omponents/support/utils/src/test/java/mozilla/components/support/utils/URLStringUtilsTest.kt
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the corrections you made!
I added a few suggestions, please feel free to ask if anything is unclear.
GitHub says "Merging is blocked - Merging can be performed automatically once the requested changes are addressed", so I'm going to try the "Re-request review" button. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for those fixes!
Let's just fix one last comment, and it's good to ship.
// All cases that behave differently are annotated with INVERT(). | ||
val INVERT: (Boolean) -> Boolean = { !it } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I forgot to specify that in my previous comment: we are adding complexity with this annotation-like function, that I think we could replace with clear comments around the tests.
We could replace the use of assertTrue(INVERT(isURLLike(xxx)))
by assertFalse(isURLLike(xxx))
. Those asserts could be gathered with a comment above explaining that the ideal regex should have the same result as the one in UrlStringUtils.kt
, but the current one gives a different result. Also explaining that we allow it for now, until bug 1685152 is fixed.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replace the use of assertTrue(INVERT(isURLLike(xxx))) by assertFalse(isURLLike(xxx)). Those asserts could be gathered with a comment
I intentionally kept assertTrue/assertFalse the same as the original tests, and replaced the comments with a programmatic annotation, in order to reduce the cognitive effort required to maintain a second copy. Your suggestion would increase complexity when both functions are considered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do understand the idea and the value of trying to keep both tests as similar as possible.
Nevertheless, this is starting a new pattern in the codebase, and maybe we should try to follow the existing conventions instead?
Maybe we could get a second opinion from someone else? cc: @jonalmeida
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! I agree with @titooan, I too would prefer avoiding new patterns. Adding these cases that should pass/fail can be in a separate section with a well-worded comment to explain that these should be have differently when the linked bug is fixed.
I intentionally kept assertTrue/assertFalse the same as the original tests, and replaced the comments with a programmatic annotation, in order to reduce the cognitive effort required to maintain a second copy. Your suggestion would increase complexity when both functions are considered.
The felt complexity of both solutions are indeed subjective. In cases like this, I would recommend the advice of the code maintainers to decide what is the more preferred way, especially in terms of conventions the codebase follows. 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏 |
bors try |
It looks like the CI we depend on for our contributor PRs is down, so I've pushed a separate branch to run all our CI tests. |
CI has passed! I've pushed a small update to correct the changelog entry since we've cut the previous version already. Let's land this! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for your contribution @pmarks-net, it looks pefect to me!
Let's land it!
This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏 |
Firefox 122 (with the IPv6 literals fix) is now live on the Play store. I'm mentioning mozilla-mobile/fenix#4343 to notify the original reporters. |
This pull request lets Firefox for Android accept IPv6 literals typed into the address bar.
For example: https://[2606:4700:4700::1111]/
The bug was originally reported as mozilla-mobile/fenix#4343, but @YoRyan's mozilla-mobile/android-components#5546 was rejected because it grew a big slow regex.
The big regex no longer exists (yay!) leaving this 1-line
isURLLenient
regex as the final roadblock.Pull Request checklist
After merge
To download an APK when reviewing a PR (after all CI tasks finished running):
Checks
at the top of the PR page.firefoxci-taskcluster
group on the left to expand all tasks.build-apk-{fenix,focus,klar}-debug
task you're interested in.View task in Taskcluster
in the newDETAILS
section.GitHub Automation
https://bugzilla.mozilla.org/show_bug.cgi?id=1803465
https://bugzilla.mozilla.org/show_bug.cgi?id=1807752