Clarify devtools.panels.create() path resolution

[bershanskiy]

Description

Fix mistake in description of devtools.panels.create().

Motivation

Make documentation correct.

Additional details

Chromium

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.

Safari

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. I did not find documentation about Safari 16 behavior so I tested Safari Technology Preview 153 (future Safari 16.0) and it used paths relative to manifest.json (like Chrome). I created this project for testing.

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

Related issues and pull requests

This difference discussed in W3C WebExtensions working group: w3c/webextensions#270

[github-actions]

Preview URLs

• /en-US/docs/Mozilla/Add-ons/WebExtensions/API/devtools/panels/create

(comment last updated: 2023-09-11 02:29:36)

[bershanskiy]

The flaw is not caused by this PR, it existed prior to this PR and was caused by BCD. Also, that underlying problem was already fixed in BCD itself: mdn/browser-compat-data#17755

[bershanskiy]

Safari 16 was released, and the BCD PR was merged (linked above), is there anything else I could do to advance this PR?

[jpmedley]

@bershanskiy As an MDN reviewer and Chrome's new person on extensions, I'm one of the most logical people to review this. I have no corrections to request. I haven't merged this because non-normative implementation differences are usually handled in BCD notes. I actually think that what you did might be temporarily correct for extensions, but I need to discuss this with Ruth. Can you hang on a bit longer?

[bershanskiy]

Thanks for the reply, I just wanted to ensure I'm not blocking anything. Regarding possible MDN update: it was not immediately clear what is the "correct"/"standard" way of handling paths, so I was not sure whether the comment should be on Firefox or all other browsers and whether subfeature should be called "Relative path resolution" or "Absolute path resolution".

[jpmedley]

I see that you're the one who opened this ticket in the spec. Are you involved in extensions or did it have more to do with you being a w3c employee? If the former, I think we might be ploying the same field. Can you send me a private email so we can compare notes? jmedley at google dot com.

Were you at TPAC last week?

[bershanskiy]

Thanks for the prompt reply! I'm just someone interested in WebExtensions and I'm not affiliated with W3C aside from being a member of a few community working groups. I missed TPAC last week, although I wish I didn't. I'll follow up in an email soon.

[bsmth]

Hi @bershanskiy, @jpmedley - just wanted to check in on the status of this one. Are we waiting on a decision whether to have browser-specific details in the prose or not? Thanks :)

[jpmedley]

As per this comment, can you please add the implementation differences to BCD repo?

Do you need help with that?

[rebloor]

Suggested change

	- : `string`. Specifies an icon which will be shown next to the title. It's provided as a URL to an image file that's been bundled with your extension. Chromium-based browsers and Safari resolve this URL as absolute, while Firefox resolves this URL as relative to the current extension page (unless expressed as an absolute URL, e.g. "/icons/panel.png").
	- : `string`. Specifies an icon that is shown next to the title. It's provided as a URL to an image file bundled with your extension. The URL may be resolved as an absolute URL or relative to the current extension page. See the browser compatibility data for more information.

[rebloor]

I've now moved this information to mdn/browser-compat-data#20617