Fixes#397
There is no mechanism for updating these files. They were last refreshed five years ago, so can no longer be guaranteed to reflect the example code. Links to these files on MDN were removed in https://github.com/mdn/content/pull/28422.
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.
