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

Inconsistency: devtools.panels.create() #270

Open
bershanskiy opened this issue Sep 10, 2022 · 9 comments
Open

Inconsistency: devtools.panels.create() #270

bershanskiy opened this issue Sep 10, 2022 · 9 comments
Labels
inconsistency Inconsistent behavior across browsers

Comments

@bershanskiy
Copy link
Member

bershanskiy commented Sep 10, 2022

devtools.panels.create(title, iconPath, pagePath) resolves iconPath and pagePath as absolute URLs in Chrome and as relative URLs in Firefox, leading to inconsistency.

Specifically, Chrome docs state:

iconPath
Path of the panel's icon relative to the extension directory.
pagePath
Path of the panel's HTML page relative to the extension directory.

MDN states (shortened):

iconPath
... The URL is resolved as relative to the current extension page (unless expressed as an absolute URL, e.g. "/icons/panel.png").
pagePath
... The URL is resolved as relative to the current extension page (unless expressed as an absolute URL, e.g. "/devtools/panel.html"). ...

I did not find documentation about Safari behavior but I tested Safari Technology Preview 153 (future Safari 16.0) and it used paths relative to the extension directory (like Chrome). I created this project for testing.

Safari 16 Beta Release Notes list under "Safari Web Extensions > New Features" there is "Added support for Safari Web Inspector Extensions", which most likely includes this method. According to MDN BCD, this method is available in Safari 16 Technology Preview (in line with release notes).

Note: some popular DevTools extensions seem to work around this difference by placing the DevTools background page into the same folder as manifest.json.

Note 2: There is apparently a bug in Chrome 99+ which makes absolute URLs produce double slashes in message's sender.url. For example, this bug affects Svelte DevTools (10000+ users on CWS). Details: sveltejs/svelte-devtools#69, two possible fixes (either one would work): sveltejs/svelte-devtools#70, sveltejs/svelte-devtools#78

@xeenon
Copy link
Collaborator

xeenon commented Sep 12, 2022

Safari treats the paths as relative to the extension directory, like Chrome.

@bershanskiy
Copy link
Member Author

Safari treats the paths as relative to the extension directory, like Chrome.

Just to clarify: in this case, the extension directory is always defined to be the directory of manifest.json, correct?

@xeenon
Copy link
Collaborator

xeenon commented Sep 13, 2022

Correct.

@carlosjeurissen
Copy link
Contributor

This is not limited to just the devtools API. Aligning this across browsers would be great.

Another workaround is to simply always use absolute URLs like the following: /icons/panel.png. Yet this might not be doable due to the double slashes issue as @bershanskiy mentions in Note 2. Is there a crbug created for this issue?

Some considerations

  • The relative path syntax makes it possible to define URLs as being relative. This also aligns with other browser APIs like changing window.location.
  • Since paths defined in manifest.json are always absolute to the extension base, to some developers it can feel natural to be able to use the same path in API method calls. This leads to less bugs in the end.

@dotproto
Copy link
Member

Note 2: There is apparently a bug in Chrome 99+ which makes absolute URLs produce double slashes in message's sender.url. For example, this bug affects Svelte DevTools (10000+ users on CWS). Details: sveltejs/svelte-devtools#69, two possible fixes (either one would work): sveltejs/svelte-devtools#70, sveltejs/svelte-devtools#78

@bershanskiy (or whoever wants to), please open an issue for this on crbug.com.

This is not limited to just the devtools API. Aligning this across browsers would be great.

Can you share more details? It might be creating a new meta issue to track the more generic inconsistency and referencing this issue from it.

@carlosjeurissen
Copy link
Contributor

@dotproto if I recall this correctly, I have been dealing with this issue myself with the browserAction.setIcon API. There might be more. Basically any API which references a path of some kind should be checked.

@bershanskiy
Copy link
Member Author

bershanskiy commented Sep 15, 2022

@bershanskiy (or whoever wants to), please open an issue for this on crbug.com.

I searched for a bug and didn't find one, so I'll create a new one soon (with a detailed repro case). I will post the link here.

It would be nice to get a consensus from all browser vendors eventually (especially from Apple since Safari 16 still could alter its behavior prior to the launch).

Also, consider adding the "next manifest version" label because this is a breaking change and is probably not very likely to be fixed in MV3 or MV2.

@carlosjeurissen
Copy link
Contributor

carlosjeurissen commented Sep 15, 2022

@dotproto Checked a few APIs manually in firefox and indeed browserAction.setIcon is handled relatively.

However, when checking the notifications API iconUrl property, this is handled absolutely.

@bershanskiy
Copy link
Member Author

FYI, I created a Chromium bug for Note 2: https://bugs.chromium.org/p/chromium/issues/detail?id=1364293

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
inconsistency Inconsistent behavior across browsers
Projects
None yet
Development

No branches or pull requests

4 participants