webextension-polyfill updates - #44951
Conversation
Rob--W
left a comment
There was a problem hiding this comment.
Could you update the text to account for mozilla/webextension-polyfill#942 ? There is a small subset of extensions where "148" does not apply, but "152" does.
|
@Rob--W updated re 152 |
Rob--W
left a comment
There was a problem hiding this comment.
I think that this might be conflicting with some other PRs, notably #44959 and the older PR at #44149 . In the interest of avoiding duplicate/overlapping work I suggest combining 44149 with this one (this one about 152+148 supersedes the part about 148).
I already approved Oliver's PR, so we could also merge that first, merge/rebase this branch. And then do a final pass for inconsistencies. I spotted at least one inconsistency, the existing claim that devtools doesn't support Promise. That note should be adjusted to state that support was added in 152.
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Co-authored-by: Rob Wu <rob@robwu.nl> Co-authored-by: rebloor <git@sherpa.co.nz>
| Firefox also supports the `chrome.*` namespace for APIs that are compatible with Chrome, primarily to assist with [porting](https://extensionworkshop.com/documentation/develop/porting-a-google-chrome-extension/). However, using the `browser.*` namespace is preferred. In addition to being the proposed standard, `browser.*` uses promises—a modern and convenient mechanism for handling asynchronous events. | ||
|
|
||
| Only in the most trivial extensions is namespace likely to be the only cross-platform issue to be addressed. Therefore, it's rarely, if ever, helpful to address this issue alone. The best approach is to address this with asynchronous event handling. | ||
|
|
There was a problem hiding this comment.
[mdn-linter] reported by reviewdog 🐶
…-support-for-the-browser-namespace
…he-browser-namespace Issue 44114 chrome support for the browser namespace
|
@Rob--W includes changes from #44149, and I've made updates, so everything should now be accurate and consistent. I'm wondering whether, when we can be reasonably assured that most new cross-browser development will target the versions supporting the browser and promises, we should review the three articles to eliminate any confusion or uncertainty about which one to consult. |
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Rob--W
left a comment
There was a problem hiding this comment.
@Rob--W includes changes from #44149, and I've made updates, so everything should now be accurate and consistent. I'm wondering whether, when we can be reasonably assured that most new cross-browser development will target the versions supporting the browser and promises, we should review the three articles to eliminate any confusion or uncertainty about which one to consult.
I'd like to preserve a historical reference because that would answer questions "why are there many ways to do the same and which is recommended?". If we can remove some duplication and instead link to a canonical article that would be nice, but let's not add that scope creep to this PR.
rebloor
left a comment
There was a problem hiding this comment.
Hmm. Chained copy-paste error?
Co-authored-by: Rob Wu <rob@robwu.nl> Co-authored-by: rebloor <git@sherpa.co.nz>
|
@Rob--W, my comment about reviewing the three articles wasn't so much about removing historical information as about making sure the current situation was as clear as possible across the API, differences, and cross-browser pages. I've made a note to myself to review and create a PR if it looks useful. |
|
@Rob--W ready for your review again |
Description
These changes are designed to emphasize that the webextension-polyfill is now only needed when an extension want to target Chrome 147 or earlier.
Related issues and pull requests
Related changes to the Extension Workshop content in mozilla/extension-workshop#2401.
Fixes #44114 (with content from Issue-44114-Chrome-support-for-the-browser-namespace)