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

fix(URLPattern): Handle search regex correctly in URLPattern #50

Conversation

yazan-abdalrahman
Copy link

No description provided.

@CLAassistant
Copy link

CLAassistant commented Jul 23, 2024

CLA assistant check
All committers have signed the CLA.

@yazan-abdalrahman
Copy link
Author

@crowlKats

before
image

after
image

@crowlKats
Copy link
Member

this does not seem to be complying to the specification.

however, I took a bit of a deeper look and one issue is we cannot update the testdata since its blocked on #35

@yazan-abdalrahman
Copy link
Author

yazan-abdalrahman commented Jul 24, 2024

this does not seem to be complying to the specification.

however, I took a bit of a deeper look and one issue is we cannot update the testdata since its blocked on #35

@crowlKats

What is the specification that this change '#50' does not comply with?

This change '#50' does not change any tests; instead, it just updates the search field's regex to match any pattern when it has a default pattern of "no pattern."

@crowlKats
Copy link
Member

@yazan-abdalrahman the specification is https://urlpattern.spec.whatwg.org.
We shouldn't be adding odd behaviour as such to achieve desired outcomes. If what we are doing is wrong, and we don't match in behaviour of the spec, then we need to change our implementation.
If instead chrome is doing things wrong, then chrome should either change or upstream their changes to the spec.

@yazan-abdalrahman
Copy link
Author

yazan-abdalrahman commented Jul 24, 2024

@yazan-abdalrahman the specification is https://urlpattern.spec.whatwg.org. We shouldn't be adding odd behaviour as such to achieve desired outcomes. If what we are doing is wrong, and we don't match in behaviour of the spec, then we need to change our implementation. If instead chrome is doing things wrong, then chrome should either change or upstream their changes to the spec.

@crowlKats
I debugged I didn't find another solution, best solution as I said first is to change the "parse constructor string" method and then update the test, I don't think this test is standard if u want to update them I can do it

  pub fn parse_constructor_string<R: RegExp>(
    pattern: &str,
    base_url: Option<Url>,
  ) -> Result<UrlPatternInit, Error> {
    let url = match Url::parse(pattern) {
      Ok(url) => url,
      Err(_) => {
        if let Some(base) = base_url {
          base.join(pattern).map_err(|_| Error::BaseUrlRequired)?
        } else {
          return Err(Error::BaseUrlRequired);
        }
      }
    };
    Ok(Self {
      protocol: Some(url.scheme().to_string()),
      username: if url.username().is_empty() {
        None
      } else {
        Some(url.username().to_string())
      },
      password: url.password().map(|s| s.to_string()),
      hostname: url.host_str().map(|s| s.to_string()),
      port: url.port().map(|p| p.to_string()),
      pathname: Some(url.path().to_string()),
      search: url.query().map(|s| s.to_string()),
      hash: url.fragment().map(|s| s.to_string()),
      base_url: None,
    })
  }

and this code it matches with specifications
image
https://urlpattern.spec.whatwg.org/
image
Because it currently sets search as default to empty, not *, and another field to the same, and that does not match specifications, it should be changed tests to comply with the specification.

image
it has one difference in this implementation to setting port i can resolve it did u need to rewrite implementations and tests?

@yazan-abdalrahman
Copy link
Author

@yazan-abdalrahman the specification is https://urlpattern.spec.whatwg.org. We shouldn't be adding odd behaviour as such to achieve desired outcomes. If what we are doing is wrong, and we don't match in behaviour of the spec, then we need to change our implementation. If instead chrome is doing things wrong, then chrome should either change or upstream their changes to the spec.

@crowlKats I debugged I didn't find another solution, best solution as I said first is to change the "parse constructor string" method and then update the test, I don't think this test is standard if u want to update them I can do it

  pub fn parse_constructor_string<R: RegExp>(
    pattern: &str,
    base_url: Option<Url>,
  ) -> Result<UrlPatternInit, Error> {
    let url = match Url::parse(pattern) {
      Ok(url) => url,
      Err(_) => {
        if let Some(base) = base_url {
          base.join(pattern).map_err(|_| Error::BaseUrlRequired)?
        } else {
          return Err(Error::BaseUrlRequired);
        }
      }
    };
    Ok(Self {
      protocol: Some(url.scheme().to_string()),
      username: if url.username().is_empty() {
        None
      } else {
        Some(url.username().to_string())
      },
      password: url.password().map(|s| s.to_string()),
      hostname: url.host_str().map(|s| s.to_string()),
      port: url.port().map(|p| p.to_string()),
      pathname: Some(url.path().to_string()),
      search: url.query().map(|s| s.to_string()),
      hash: url.fragment().map(|s| s.to_string()),
      base_url: None,
    })
  }

and this code it matches with specifications image https://urlpattern.spec.whatwg.org/ image Because it currently sets search as default to empty, not *, and another field to the same, and that does not match specifications, it should be changed tests to comply with the specification.

image it has one difference in this implementation to setting port i can resolve it did u need to rewrite implementations and tests?

@crowlKats ?

@crowlKats
Copy link
Member

Apologies about the delay @yazan-abdalrahman, was going through the backlog of urlpattern related PRs and issues. This was inadvertently fixed in #44 correctly, so will close this PR.

@crowlKats crowlKats closed this Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants