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

Issue with "Browser Extensions": sub-documents not clear about limited availability of API #1903

Open
randycasburn opened this issue Jan 30, 2021 · 8 comments
Assignees
Labels
Content:WebExt WebExtensions docs on hold Waiting on something else before this can be moved forward. p2 Minor issue with low priority, can be fixed later.

Comments

@randycasburn
Copy link
Contributor

MDN URL: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions

What information was incorrect, unhelpful, or incomplete?

Related issues: mdn/browser-compat-data#8906 (comment)

Not incorrect exactly, but sub-documents require review in order to clarify the context of existence.

Specific section or headline?

All sub-documents related to "WebExtensions"

What did you expect to see?

When entering MDN from a search engine result, uses often access the sub-documents directly via a link on the search results page. When this occurs, the user is not clearly notified that the APIs documented here are for "WebExtensions" and will not work within the browser natively. This causes confusion unless the user happens to notice the crumb-trail mention of "Web Extensions" and actually knows what that means and how it relates to the content on the document.

It would be better if the each sub-document clearly stated near the top of the document that this API is meant for use with "Web Extensions" only.

For your consideration.

Did you test this? If so, how?

Search web for "windows.WindowState" navigate directly to the API sub-document. Try to determine that this API is only for use with WebExtensions.

MDN Content page report details
@Ryuno-Ki Ryuno-Ki added the Content:WebExt WebExtensions docs label Jan 30, 2021
@rebloor rebloor added the P4 label Aug 10, 2021
@github-actions github-actions bot added the idle label Dec 8, 2021
@teoli2003 teoli2003 reopened this May 29, 2022
@github-actions github-actions bot added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label May 29, 2022
@sideshowbarker sideshowbarker removed the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label May 30, 2022
@rebloor
Copy link
Contributor

rebloor commented Sep 13, 2022

@Rumyra@mixedpuppy suggests that this probably falls within your bailiwick or for someone else who's working on MDN.

@Rumyra
Copy link
Collaborator

Rumyra commented Oct 24, 2022

Thanks @rebloor - I wonder if we can address it within the strategy of add-ons -> web-extensions (which still needs planning)

@rebloor
Copy link
Contributor

rebloor commented Oct 24, 2022

@Rumyra by the "strategy of add-ons -> web-extensions" I assume you effectively mean removing add-ons from the hierarchy, as highlighted with the oval below. I don't think that would address the reporter's concern. Their concern is that if you land on a web extensions API page, it's not clear that the API only applies to web extensions. I think they were looking for something more along the lines of the red box in the screenshot.
image

@randycasburn
Copy link
Contributor Author

randycasburn commented Oct 24, 2022 via email

@Rumyra
Copy link
Collaborator

Rumyra commented Nov 17, 2022

Sorry I'll elaborate:

We're currently implementing 'page-types' for MDN pages (see #15539). While web ext isn't in the first phase I envisage when we move these docs we can consider page types at the same time.

We can then use this page-type data to automatically add notes such as this to pages.

Another thing to note is we're working on a roadmap this quarter and that should help to define the time scale for this next year 👍

@rebloor rebloor added awaiting response Awaiting for author to address review/feedback on hold Waiting on something else before this can be moved forward. and removed awaiting response Awaiting for author to address review/feedback labels Nov 20, 2023
@Josh-Cena Josh-Cena removed the on hold Waiting on something else before this can be moved forward. label Jun 12, 2024
@rebloor
Copy link
Contributor

rebloor commented Jun 16, 2024

@Josh-Cena what information do you have about activity on this one, e.g. why did you remove on-hold?

@Josh-Cena
Copy link
Member

@rebloor There's no pending work that would block this from becoming reality—the WebExt docs already have page-types. Did you add on hold because the WebExt team thinks there's something else to be done first, or because you have no interest in doing it?

@rebloor
Copy link
Contributor

rebloor commented Jun 18, 2024

@Josh-Cena I've flagged this as on hold because, according to my understanding, no decision has been made about whether such a note should be added to the API pages. @Rumyra has there been any further discussion on this?

@rebloor rebloor added the on hold Waiting on something else before this can be moved forward. label Jun 18, 2024
@pransh15 pransh15 added p2 Minor issue with low priority, can be fixed later. and removed p4 labels Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Content:WebExt WebExtensions docs on hold Waiting on something else before this can be moved forward. p2 Minor issue with low priority, can be fixed later.
Projects
None yet
Development

No branches or pull requests

8 participants