Open Bug 1350523 Opened 7 years ago Updated 2 years ago

WebExtensions Permission match pattern failed to match on port

Categories

(WebExtensions :: General, defect, P3)

54 Branch
defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: swk.junk, Unassigned)

References

()

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2950.0 Iron Safari/537.36

Steps to reproduce:

I created a WebExtensions with permission match pattern "http://127.0.0.1:1234/". I then added a content script to make a Ajax request to http://127.0.0.1:1234/aaa. Firefox shows no error message, yet the server never received the request. However, when I change the pattern to "http://*/", it works as expected. When the port is the default port, it works as well.


Actual results:

Firefox shows no error message, yet the server never received the request.


Expected results:

A request should be sent.
No "port" on https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Match_patterns.
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
(In reply to swk.junk from comment #0)
> "http://127.0.0.1:1234/". 

Just omit the port: "http://127.0.0.1/", match patterns don't distinguish on port numbers.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Product: Toolkit → WebExtensions

Match patterns in Firefox do currently not support ports (bug 1362809).

When a match pattern with a port is present in the permissions section, a warning appears but the permission doesn't actually grant access. This has been reported at https://github.com/mdn/content/issues/5718. I discussed the issue with Luca, and rather than complicating the documentation, we can fix this (and improve compatibility).

We can easily address this issue by stripping ports from the host permission. Paths are already stripped from the permission even if present, stripping ports would be consistent with that.

Currently the port is included in the permission warning, but we can also remove that - the permission warning should only include the host name anyway (the scheme and path are already stripped, removing the port would be consistent too).

Status: RESOLVED → REOPENED
Component: Untriaged → General
Ever confirmed: true
Priority: -- → P3
Resolution: INVALID → ---
See Also: → 1362809
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.