These examples are designed to be cross-browser compatible.
In particular, these extensions do not use `background` because there is
currently no single manifest that can support both Firefox and Chrome,
due to the lack of event page support in Chrome, and the lack of service
worker support in Firefox.
Three examples demonstrating the use of the declarativeNetRequest API:
- dnr-block-only: One minimal example demonstrating the use of static
DNR rules to block requests.
- dnr-redirect-url: One minimal example demonstrating the use of static
DNR rules to redirect requests.
- dnr-dynamic-with-options: A generic example demonstrating how host
permissions can be requested and free forms to input DNR rules.
* Extension now is up-to-date with the Menus API
In the previous version of this extension, the author used a comment to
explain that the `browser.menus.onClicked.addListener` event listener
doesn't pass the current check state of a checkbox menu.
To solve this, an additional variable checkedState was used to keep
track of the current value of the context menu.
But now, this function is supported by the menus API in Firefox.
I changed the code to reflect how you would use it with the recent
versions, making it easier for new developers to learn this
functionality.
* Comment now reflects new function body
* Made background script of context-menu-copy-link-with-types non-persistent. Now clearing errors that could result from background.js context menu creation happening more than once.
* Suggestions from code review
* Syntax error and formatting
* Added note about () => void browser.runtime.lastError
* Feedback suggestion
Co-authored-by: Rob Wu <rob@robwu.nl>
---------
Co-authored-by: rebloor <git@sherpa.co.nz>
Co-authored-by: Rob Wu <rob@robwu.nl>
* Don't use <div /> as a button
Addition to https://github.com/mdn/content/pull/21410
* stick to old styling
* Update beastify/popup/choose_beast.html
Co-authored-by: Estelle Weyl <estelle@openwebdocs.org>
* Update beastify/popup/choose_beast.css
Co-authored-by: Estelle Weyl <estelle@openwebdocs.org>
* fix: check for button type at event listener
* fix: align css selectors to changes
Co-authored-by: Estelle Weyl <estelle@openwebdocs.org>
Instructs user to view console output via "Inspect" button on extensions page, since there was no output using the previous instructions.
Additionally, updates expected output.
The `new URL(url)` statement will throw an error if the supplied
string is not a valid URL. Adding a note to the function to clarify
that as requested by @Rob--W.
By using the URL interface, the user is ascertained that the piece of
code does not manipulate the DOM. Keeping them in the right mental
context for the example.
The apply-css example uses the protocol of the URL of the tab to
determine if a pageAction should be shown. Any page that is hosted
over http or https will receive the page action.
The former implementation creates an anchor tag, assigns the URL to
that, and fetches the protocol from there. This PR alters that to
using the URL interface. This makes it clear to the user that we're
staying in JavaScript land and will not start manipulating the visible
DOM. I would argue this is cleaner all together, but I'm very open to
learning about a different opinion.
The URL interface is more broadly supported than the
pageAction.setIcon which this example is also dependent on, so this
change should not change compatibility of this Browser Extension.
* Remove required theme aliases
Replaced uses of headerURL, accentcolor, and textcolor with theme_frame, frame, and tab_background_text. Tested and confirmed all extensions working as expected.
* Fixed another reference to headerURL
Co-authored-by: Richard Bloor <rbloor@atlassian.com>
* New user script example
This PR is the content from [PR 426](https://github.com/mdn/webextensions-examples/pull/426), originally submitted by Irene, addressing the feedback on the readme content.
* Including the following changes:
* renaming the content script example and updating the readme file to reference the user script example
* renaming the user script example and versioning as v1
* addressing feedback on the user script example: limiting input to hosts and script, addressing code and HTML/CSS comments
I haven't changed the "eating" script example, I feel it is useful to have similar demonstrations in the content and user script examples to make it easier for developers to compare and contrast.
* Various changes for feedback
* Added a user script ID that is stored in the registered script's metadata and then used in the API script to key the data stored in local storage
* Update to emphasize scoping of local storage using an ID provided in the user script metadata
Co-authored-by: Richard Bloor <rbloor@atlassian.com>