Skip to content
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

Merged
merged 18 commits into from Nov 22, 2023

Conversation

pmarks-net
Copy link
Contributor

@pmarks-net pmarks-net commented Oct 14, 2023

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

  • Quality: This PR builds and passes detekt/ktlint checks (A pre-push hook is recommended)
  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Changelog: This PR includes a changelog entry or does not need one
  • Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features

After merge

  • Breaking Changes: If this is a breaking Android Components change, please push a draft PR on Reference Browser to address the breaking issues.

To download an APK when reviewing a PR (after all CI tasks finished running):

  1. Click on Checks at the top of the PR page.
  2. Click on the firefoxci-taskcluster group on the left to expand all tasks.
  3. Click on the build-apk-{fenix,focus,klar}-debug task you're interested in.
  4. Click on View task in Taskcluster in the new DETAILS section.
  5. The APK links should be on the right side of the screen, named for each CPU architecture.

GitHub Automation

https://bugzilla.mozilla.org/show_bug.cgi?id=1803465
https://bugzilla.mozilla.org/show_bug.cgi?id=1807752

@github-actions github-actions bot added the 🕵️‍♀️ needs review PRs that need to be reviewed label Oct 14, 2023
@pmarks-net
Copy link
Contributor Author

@csadilek and @mcomella originally wrote this regex.

@pmarks-net
Copy link
Contributor Author

pmarks-net commented Oct 14, 2023

I tested this using https://firefox-source-docs.mozilla.org/mobile/android/fenix.html and ./gradlew support-utils:test.

I'm not sure if the 3 workflow failures are my fault, nor how to rerun them.
Edit: Fixed the failures by wrapping a long line in WebURLFinder.kt.

@github-actions
Copy link
Contributor

🚧 Commit message is using the wrong format: Fix [MaxLineLength] code style failure.

The comment message should look like:

    Bug xxxx - Short description of your change
    Optionally, a longer description of the change.

@Djfe
Copy link

Djfe commented Oct 15, 2023

great, thank you for working on this 👍
Would it make sense to also introduce some assertFalse?
like for misspelled ipv6 style urls?

edit: also there is no positive test for a full URL without a double colon, like this one:
http://[2a03:2260:3006:115:3e37:12ff:fe82:cbab]/

@pmarks-net
Copy link
Contributor Author

@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.

@pmarks-net
Copy link
Contributor Author

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:

  • http://x:x -> "Invalid Address"
  • x://x -> blank tab

@github-actions
Copy link
Contributor

🚧 Commit message is using the wrong format: Import translations from android-l10n

The comment message should look like:

    Bug xxxx - Short description of your change
    Optionally, a longer description of the change.

@mergify
Copy link
Contributor

mergify bot commented Oct 24, 2023

This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏

Copy link
Contributor

mergify bot commented Nov 3, 2023

This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏

@pmarks-net
Copy link
Contributor Author

I'm still waiting for a reviewer. @csadilek perhaps?

Copy link
Contributor

@titooan titooan left a 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.

@titooan titooan self-requested a review November 17, 2023 16:13
@github-actions github-actions bot added approved PR that has been approved and removed 🕵️‍♀️ needs review PRs that need to be reviewed labels Nov 17, 2023
Copy link
Contributor

@titooan titooan left a 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-actions github-actions bot added 🕵️‍♀️ needs review PRs that need to be reviewed and removed approved PR that has been approved labels Nov 17, 2023
@pmarks-net
Copy link
Contributor Author

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.

Copy link
Contributor

@titooan titooan left a 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.

Comment on lines 138 to 139
// All cases that behave differently are annotated with INVERT().
val INVERT: (Boolean) -> Boolean = { !it }
Copy link
Contributor

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? 

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Collaborator

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. 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

Copy link
Contributor

mergify bot commented Nov 21, 2023

This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏

@titooan
Copy link
Contributor

titooan commented Nov 22, 2023

bors try

@github-actions github-actions bot mentioned this pull request Nov 22, 2023
4 tasks
@jonalmeida
Copy link
Collaborator

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.

@jonalmeida
Copy link
Collaborator

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!

@jonalmeida jonalmeida added 🛬 needs landing (squash) PRs that are ready to land (squashed) and removed 🕵️‍♀️ needs review PRs that need to be reviewed labels Nov 22, 2023
Copy link
Contributor

@titooan titooan left a 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!

@titooan titooan added the approved PR that has been approved label Nov 22, 2023
Copy link
Contributor

mergify bot commented Nov 22, 2023

This pull request has conflicts when rebasing. Could you fix it @pmarks-net? 🙏

@mergify mergify bot merged commit ec7b003 into mozilla-mobile:main Nov 22, 2023
126 checks passed
@pmarks-net
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved PR that has been approved 🛬 needs landing (squash) PRs that are ready to land (squashed)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants