From 688b99e1359f487320489bc5fd4128deeab6458f Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Wed, 17 Sep 2025 21:20:10 -0400 Subject: [PATCH 1/8] New page on filing browser bugs --- files/en-us/_redirects.txt | 7 +- files/en-us/_wikihistory.json | 20 +++--- .../web_mechanics/file_browser_bugs/index.md | 60 +++++++++++++++++ .../how_to/file_aria-related_bugs/index.md | 66 ------------------- .../web/accessibility/aria/how_to/index.md | 10 --- files/en-us/web/accessibility/aria/index.md | 2 +- files/sidebars/accessibilitysidebar.yaml | 3 - 7 files changed, 75 insertions(+), 93 deletions(-) create mode 100644 files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md delete mode 100644 files/en-us/web/accessibility/aria/how_to/file_aria-related_bugs/index.md delete mode 100644 files/en-us/web/accessibility/aria/how_to/index.md diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt index 42721fa05e47c2e..bbf38faf209a402 100644 --- a/files/en-us/_redirects.txt +++ b/files/en-us/_redirects.txt @@ -53,7 +53,7 @@ /en-US/docs/ARIA/ARIA_Techniques/Using_the_toolbar_role /en-US/docs/Web/Accessibility/ARIA/Reference/Roles/toolbar_role /en-US/docs/ARIA/Accessible_Rich_Internet_Applications /en-US/docs/Web/Accessibility/ARIA /en-US/docs/ARIA/Basic_form_hints /en-US/docs/Web/Accessibility/ARIA -/en-US/docs/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs +/en-US/docs/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs /en-US/docs/ARIA/Live_Regions /en-US/docs/Web/Accessibility/ARIA/Guides/Live_regions /en-US/docs/ARIA/examples /en-US/docs/Web/Accessibility/ARIA /en-US/docs/ARIA/widgets /en-US/docs/Web/Accessibility/ARIA @@ -100,7 +100,7 @@ /en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_toolbar_role /en-US/docs/Web/Accessibility/ARIA/Reference/Roles/toolbar_role /en-US/docs/Accessibility/ARIA/ARIA_Test_Cases /en-US/docs/Web/Accessibility/ARIA /en-US/docs/Accessibility/ARIA/Basic_form_hints /en-US/docs/Web/Accessibility/ARIA -/en-US/docs/Accessibility/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs +/en-US/docs/Accessibility/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs /en-US/docs/Accessibility/ARIA/Web_applications_and_ARIA_FAQ /en-US/docs/Web/Accessibility/ARIA /en-US/docs/Accessibility/ARIA/examples /en-US/docs/Web/Accessibility/ARIA /en-US/docs/Accessibility/ARIA/forms /en-US/docs/Web/Accessibility/ARIA @@ -11616,7 +11616,8 @@ /en-US/docs/Web/Accessibility/ARIA/Attributes/aria-valuenow /en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-valuenow /en-US/docs/Web/Accessibility/ARIA/Attributes/aria-valuetext /en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-valuetext /en-US/docs/Web/Accessibility/ARIA/Basic_form_hints /en-US/docs/Web/Accessibility/ARIA -/en-US/docs/Web/Accessibility/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs +/en-US/docs/Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs /en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs +/en-US/docs/Web/Accessibility/ARIA/How_to_file_ARIA-related_bugs /en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs /en-US/docs/Web/Accessibility/ARIA/Multipart_labels /en-US/docs/Web/Accessibility/ARIA/Guides/Multipart_labels /en-US/docs/Web/Accessibility/ARIA/Roles /en-US/docs/Web/Accessibility/ARIA/Reference/Roles /en-US/docs/Web/Accessibility/ARIA/Roles/ARIA:_tabpanel_role /en-US/docs/Web/Accessibility/ARIA/Reference/Roles/tabpanel_role diff --git a/files/en-us/_wikihistory.json b/files/en-us/_wikihistory.json index d703ccbee67c884..e565fc842d80613 100644 --- a/files/en-us/_wikihistory.json +++ b/files/en-us/_wikihistory.json @@ -10873,6 +10873,16 @@ "Mateen" ] }, + "Learn_web_development/Howto/Web_mechanics/File_browser_bugs": { + "modified": "2019-03-24T00:12:10.850Z", + "contributors": [ + "chrisdavidmills", + "carlkibler", + "bledwards1", + "Sheppy", + "Aaronlev" + ] + }, "Learn_web_development/Howto/Web_mechanics/How_does_the_Internet_work": { "modified": "2020-07-16T22:35:35.495Z", "contributors": [ @@ -70984,16 +70994,6 @@ "SteveLee" ] }, - "Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs": { - "modified": "2019-03-24T00:12:10.850Z", - "contributors": [ - "chrisdavidmills", - "carlkibler", - "bledwards1", - "Sheppy", - "Aaronlev" - ] - }, "Web/Accessibility/ARIA/Reference/Roles": { "modified": "2020-04-01T14:49:41.249Z", "contributors": [ diff --git a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md new file mode 100644 index 000000000000000..717af3ec89e672d --- /dev/null +++ b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md @@ -0,0 +1,60 @@ +--- +title: How to file bugs with browsers +slug: Learn_web_development/Howto/Web_mechanics/File_browser_bugs +page-type: learn-faq +sidebar: learn-how-to +--- + +Browsers are software, and software has bugs. Sometimes you may find that your code doesn't behave the way you expected (or the way documentation indicates), and that could either be a bug in your code, a bug in the documentation (let's hope not!), or a bug in the browser you're using. We'll discuss how to figure out which it is, and how to file a bug if it turns out to be a browser bug. + +## Whose bug is it? + +Before filing a bug to the browser, you should make sure that the bug is real. It could be in one of four places: your code, the documentation, the browser, or the specification. Generally, the specification is the most credible source of all; browsers and documentation both follow the spec and can be wrong; your code... well, the quality depends on you. + +The first step is to extract a minimal test case that reproduces the bug. It should be small and standalone, preferably a single HTML file with embedded CSS and JavaScript, without external dependencies or unrelated code. This is useful for two reasons: it minimizes the possibility that the problem is in your own code, and you need to provide one anyway if you want to discuss it with anyone, including filing a bug. For example, the following would be a good test case for a bug related to the {{cssxref(":autofill")}} pseudo-class. Note how we stripped it down to the bare minimum, which means foregoing some best practices like the doctype, `` and `` tags, labels for inputs, etc. But that's okay, because the relevant code is still there. + +```html + + + +``` + +You can either save this HTML code locally and open it using the `file://` protocol, or you can use an online service like [JSFiddle](https://jsfiddle.net/) or [CodePen](https://codepen.io/) to create a live demo. Now, the simplest way to test if it's a browser bug is to open the test case in [multiple browsers](/en-US/docs/Learn_web_development/Extensions/Testing/Introduction). Preferably use three browsers (Chromium-based, Firefox, and Safari), so if the other two behave the same way (and align with the docs), you can be pretty sure that the third one has a bug. + +> [!NOTE] +> There are other practices related to isolating reproduction, like testing in a private window, disabling extensions, clearing caches, etc. You should also try those before reporting the bug. + +Of course, even if all three browsers behave the same way, it could still be a bug in all of them; or, two browsers may have the same bug, while the third one is correct. To be sure, you need to read the specification. Documentation may be out of date or incorrect, but the specification is the source of truth. On every MDN reference page, you can find links to the relevant specifications in the "Specifications" section. Sometimes specifications are hard to read, but try your best—if it turns out that all browsers and the spec are consistent but MDN is wrong, consider [contributing](/en-US/docs/MDN/Community/Getting_started)! + +Let's say you found a divergence between the browsers and the spec. This isn't necessarily a bug. Browsers may implement something that's not merged into the spec yet, or they may have not yet implemented a new part of the spec. At this point, you need to check more sources to see what the implementation story is. Here are some places to look: + +- MDN's browser compatibility table. In the "Browser compatibility" section, you may find information about which browsers support a feature and to what extent. This may indicate that a feature is not implemented in your target browser, or that it's only partially implemented (i.e., it has known bugs or limitations). +- The specification repo. WHATWG, CSSWG, TC39, and most other standard bodies work publicly on GitHub, so you can check if the spec was recently changed, or if there's an open issue about the feature you're testing. +- Community forums. The [MDN community](/en-US/docs/MDN/Community/Communication_channels) is a great place to start, or you can find other web-related forums, where you can ask about whether browsers haven't implemented something yet, or if there's a known bug. +- The issue tracker for the browser you're testing. If you find something related, that means the bug is real, but there's nothing you need to do in the end. We'll get to that next. + +## Browser bug trackers + +Each browser has its own bug tracker, where you can search for existing bugs and file new ones. The interface and process may be slightly unfamiliar at first, but there are usually instructions. The table below lists the bug trackers for the major browsers. + +| Browser | Bug tracker | +| --------------- | ----------------------------------------------------- | +| Apple Safari | [WebKit Bugzilla](https://webkit.org/reporting-bugs/) | +| Google Chrome | [Chromium Issues](https://issues.chromium.org/issues) | +| Mozilla Firefox | [Mozilla Bugzilla](https://bugzilla.mozilla.org/) | +| Opera | [Opera Bug Wizard](https://bugs.opera.com/wizard/) | + +Remember to search for existing bugs before filing a new one. If you find an existing bug that matches your issue, you can add a comment with your findings (for example, if you found a workaround, or if you have more information about the bug); but don't add comments that don't really add value. If you can't find an existing bug, you can file a new one—someone would tell you if it's a duplicate. When filing a new bug, make sure to include your minimal test case, and any other information that the report form asks for, like browser version, expected and actual results, etc. Some bug trackers may also ask you to select a component or area for the bug; just do your best. Someone will re-assign it if needed. + +## Filing bugs for assistive technologies + +If the bug is related to a non-browser software, such as a screen reader, you need to file the bug with the relevant software vendor. The table below lists some of the most popular assistive technologies and where to file bugs for them. + +| Software | Where to file | +| ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | +| [Freedom Scientific JAWS](https://www.freedomscientific.com/products/software/jaws/) | [JAWS technical support form](https://support.freedomscientific.com/Forms/TechSupport) | +| [Non Visual Desktop Access (NVDA)](https://www.nvaccess.org/) | [File NVDA bugs](https://github.com/nvaccess/nvda) | diff --git a/files/en-us/web/accessibility/aria/how_to/file_aria-related_bugs/index.md b/files/en-us/web/accessibility/aria/how_to/file_aria-related_bugs/index.md deleted file mode 100644 index fe728676ce9510c..000000000000000 --- a/files/en-us/web/accessibility/aria/how_to/file_aria-related_bugs/index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: How to file ARIA-related bugs -slug: Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs -page-type: guide -sidebar: accessibilitysidebar ---- - -The state of ARIA technology has always depended on the community. If you notice an implementation issue, please take a little time and let the developers know. Here's where to file bugs: - -### Screen Readers - - - - - - - - - - - - - - - - - - - - - -
SoftwareWhere to fileNotes
Freedom Scientific JAWSJAWS technical support form
Non Visual Desktop Access (NVDA)File NVDA bugsDiscuss NVDA issues
- -### Browsers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SoftwareWhere to fileNotes
Apple SafariFile WebKit.org bugs
Google ChromeFile Chromium bugs
Mozilla FirefoxFile Firefox bugs Use Component: Disability Access APIs
OperaFile Opera bugsUse [ARIA] in the summary field
diff --git a/files/en-us/web/accessibility/aria/how_to/index.md b/files/en-us/web/accessibility/aria/how_to/index.md deleted file mode 100644 index 58f80dff585da65..000000000000000 --- a/files/en-us/web/accessibility/aria/how_to/index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: How to -slug: Web/Accessibility/ARIA/How_to -page-type: listing-page -sidebar: accessibilitysidebar ---- - -How-to guides for Accessible Rich Internet Applications (ARIA). - -{{SubPagesWithSummaries}} diff --git a/files/en-us/web/accessibility/aria/index.md b/files/en-us/web/accessibility/aria/index.md index 6e0eda0ba1dc517..0c5f5d07d0739f3 100644 --- a/files/en-us/web/accessibility/aria/index.md +++ b/files/en-us/web/accessibility/aria/index.md @@ -84,7 +84,7 @@ The [ARIA reference](/en-US/docs/Web/Accessibility/ARIA/Reference) is a comprehe ## Guides -The [ARIA guides](/en-US/docs/Web/Accessibility/ARIA/Guides) and [How-to pages](/en-US/docs/Web/Accessibility/ARIA/How_to) are resources that help you improve the accessibility of web page features such as tables, forms, and keyboard-navigation. +The [ARIA guides](/en-US/docs/Web/Accessibility/ARIA/Guides) are resources that help you improve the accessibility of web page features such as tables, forms, and keyboard-navigation. ## Standardization efforts diff --git a/files/sidebars/accessibilitysidebar.yaml b/files/sidebars/accessibilitysidebar.yaml index 71f0763feefc3bf..6c7280a1f443036 100644 --- a/files/sidebars/accessibilitysidebar.yaml +++ b/files/sidebars/accessibilitysidebar.yaml @@ -42,9 +42,6 @@ sidebar: - /Web/Accessibility/ARIA/Guides/Screen_Reader_Implementors - /Web/Accessibility/ARIA/Guides/Techniques - /Web/Accessibility/ARIA/Guides/Multipart_labels - - type: section - link: /Web/Accessibility/ARIA/How_to - - /Web/Accessibility/ARIA/How_to/File_ARIA-related_bugs - type: section link: /Web/Accessibility/ARIA/Reference title: ARIA reference From a25f8f2b8a2006afd47798280e409f1ae9e8c304 Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Tue, 23 Sep 2025 22:18:04 -0400 Subject: [PATCH 2/8] Add see also --- .../web_standards/how_browsers_load_websites/index.md | 5 +++++ .../howto/web_mechanics/file_browser_bugs/index.md | 2 +- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/files/en-us/learn_web_development/getting_started/web_standards/how_browsers_load_websites/index.md b/files/en-us/learn_web_development/getting_started/web_standards/how_browsers_load_websites/index.md index 5ab691ea8edf480..d66f3a24c64422d 100644 --- a/files/en-us/learn_web_development/getting_started/web_standards/how_browsers_load_websites/index.md +++ b/files/en-us/learn_web_development/getting_started/web_standards/how_browsers_load_websites/index.md @@ -179,4 +179,9 @@ On the upside, the web is also an awesome programming environment, for many reas - App updates are usually straightforward. In many cases, visitors can see new versions of an application when they reload their browser tab. You don't need to worry about getting visitors to regularly download and install software updates. - The web community is vibrant and helpful. As we discuss later on in our [Research and learning](/en-US/docs/Learn_web_development/Getting_started/Soft_skills/Research_and_learning) article, there are lots of places you can go to ask for help, and great resources available to learn from. +## See also + +- [How to file bugs with browsers](/en-US/docs/Learn_web_development/Howto/Web_mechanics/File_browser_bugs) + - : If something isn't working as you expect in a browser, it could be a bug in the browser. This article explains how to figure out if it is, and how to file a bug report if so. + {{PreviousMenuNext("Learn_web_development/Getting_started/Web_standards/The_web_standards_model", "Learn_web_development/Getting_started/Soft_skills", "Learn_web_development/Getting_started/Web_standards")}} diff --git a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md index 717af3ec89e672d..960c3b68164c8dc 100644 --- a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md +++ b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md @@ -33,7 +33,7 @@ Of course, even if all three browsers behave the same way, it could still be a b Let's say you found a divergence between the browsers and the spec. This isn't necessarily a bug. Browsers may implement something that's not merged into the spec yet, or they may have not yet implemented a new part of the spec. At this point, you need to check more sources to see what the implementation story is. Here are some places to look: - MDN's browser compatibility table. In the "Browser compatibility" section, you may find information about which browsers support a feature and to what extent. This may indicate that a feature is not implemented in your target browser, or that it's only partially implemented (i.e., it has known bugs or limitations). -- The specification repo. WHATWG, CSSWG, TC39, and most other standard bodies work publicly on GitHub, so you can check if the spec was recently changed, or if there's an open issue about the feature you're testing. +- The specification repo. [WHATWG](https://github.com/whatwg) (who standardize DOM, HTML, fetch, and more), [CSSWG](https://github.com/w3c/csswg-drafts) (who standardize CSS), [TC39](https://github.com/tc39) (who standardize JavaScript), and most other standard bodies work publicly on GitHub, so you can check if the spec was recently changed, or if there's an open issue about the feature you're testing. - Community forums. The [MDN community](/en-US/docs/MDN/Community/Communication_channels) is a great place to start, or you can find other web-related forums, where you can ask about whether browsers haven't implemented something yet, or if there's a known bug. - The issue tracker for the browser you're testing. If you find something related, that means the bug is real, but there's nothing you need to do in the end. We'll get to that next. From d0e74cc3a378a531ef2ab0bcf3d6aecb35195159 Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Wed, 24 Sep 2025 12:27:37 -0400 Subject: [PATCH 3/8] Rewrite --- .../howto/web_mechanics/file_browser_bugs/index.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md index 960c3b68164c8dc..af997c8a6701476 100644 --- a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md +++ b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md @@ -23,20 +23,20 @@ The first step is to extract a minimal test case that reproduces the bug. It sho ``` -You can either save this HTML code locally and open it using the `file://` protocol, or you can use an online service like [JSFiddle](https://jsfiddle.net/) or [CodePen](https://codepen.io/) to create a live demo. Now, the simplest way to test if it's a browser bug is to open the test case in [multiple browsers](/en-US/docs/Learn_web_development/Extensions/Testing/Introduction). Preferably use three browsers (Chromium-based, Firefox, and Safari), so if the other two behave the same way (and align with the docs), you can be pretty sure that the third one has a bug. +You can either save this HTML code locally and [serve it locally](/en-US/docs/Learn_web_development/Howto/Tools_and_setup/set_up_a_local_testing_server), or you can use an online service like [JSFiddle](https://jsfiddle.net/) or [CodePen](https://codepen.io/) to create a live demo. Now, the simplest way to test if it's a browser bug is to open the test case in [multiple browsers](/en-US/docs/Learn_web_development/Extensions/Testing/Introduction). This way, if there's a divergence, it's more likely to be a browser bug. > [!NOTE] > There are other practices related to isolating reproduction, like testing in a private window, disabling extensions, clearing caches, etc. You should also try those before reporting the bug. -Of course, even if all three browsers behave the same way, it could still be a bug in all of them; or, two browsers may have the same bug, while the third one is correct. To be sure, you need to read the specification. Documentation may be out of date or incorrect, but the specification is the source of truth. On every MDN reference page, you can find links to the relevant specifications in the "Specifications" section. Sometimes specifications are hard to read, but try your best—if it turns out that all browsers and the spec are consistent but MDN is wrong, consider [contributing](/en-US/docs/MDN/Community/Getting_started)! - -Let's say you found a divergence between the browsers and the spec. This isn't necessarily a bug. Browsers may implement something that's not merged into the spec yet, or they may have not yet implemented a new part of the spec. At this point, you need to check more sources to see what the implementation story is. Here are some places to look: +Start by trusting the documentation you read and investigating the browser(s) whose behavior doesn't conform to the docs. Not all unexpected behaviors are bugs. Browsers may implement something that's not merged into the spec yet (and not documented yet), or they may have not yet implemented a new part of the spec. At this point, you need to check more sources to see what the implementation story is. Here are some places to look: - MDN's browser compatibility table. In the "Browser compatibility" section, you may find information about which browsers support a feature and to what extent. This may indicate that a feature is not implemented in your target browser, or that it's only partially implemented (i.e., it has known bugs or limitations). - The specification repo. [WHATWG](https://github.com/whatwg) (who standardize DOM, HTML, fetch, and more), [CSSWG](https://github.com/w3c/csswg-drafts) (who standardize CSS), [TC39](https://github.com/tc39) (who standardize JavaScript), and most other standard bodies work publicly on GitHub, so you can check if the spec was recently changed, or if there's an open issue about the feature you're testing. - Community forums. The [MDN community](/en-US/docs/MDN/Community/Communication_channels) is a great place to start, or you can find other web-related forums, where you can ask about whether browsers haven't implemented something yet, or if there's a known bug. - The issue tracker for the browser you're testing. If you find something related, that means the bug is real, but there's nothing you need to do in the end. We'll get to that next. +Of course, even if all browsers behave the same way, it could still be a bug in all of them; or, maybe only a single browser is implementing the intended behavior. Documentation may be out of date or incorrect. To be absolutely sure, you should regard the specification as the source of truth (except for the rare case of browsers implementing things ahead of the spec). On every MDN reference page, you can find links to the relevant specifications in the "Specifications" section. Sometimes specifications are hard to read, but try your best—if it turns out that all browsers and the spec are consistent but MDN is wrong, consider [contributing](/en-US/docs/MDN/Community/Getting_started)! + ## Browser bug trackers Each browser has its own bug tracker, where you can search for existing bugs and file new ones. The interface and process may be slightly unfamiliar at first, but there are usually instructions. The table below lists the bug trackers for the major browsers. @@ -48,11 +48,13 @@ Each browser has its own bug tracker, where you can search for existing bugs and | Mozilla Firefox | [Mozilla Bugzilla](https://bugzilla.mozilla.org/) | | Opera | [Opera Bug Wizard](https://bugs.opera.com/wizard/) | -Remember to search for existing bugs before filing a new one. If you find an existing bug that matches your issue, you can add a comment with your findings (for example, if you found a workaround, or if you have more information about the bug); but don't add comments that don't really add value. If you can't find an existing bug, you can file a new one—someone would tell you if it's a duplicate. When filing a new bug, make sure to include your minimal test case, and any other information that the report form asks for, like browser version, expected and actual results, etc. Some bug trackers may also ask you to select a component or area for the bug; just do your best. Someone will re-assign it if needed. +Search for existing bug reports before filing a new one. If you find an existing bug report that matches your issue, you can add a comment with your findings (for example, if you found a workaround, or if you have more information about the bug). However, don't add comments such as "I found this bug too", because they don't really add any value. If you can't find an existing bug, you can file a new one—someone will tell you if it's a duplicate. + +When filing a new bug, make sure to include your minimal test case, and any other information that the report form asks for, like browser version, expected and actual results, etc. Some bug trackers may also ask you to select a component or area for the bug; just do your best. Someone will re-assign it if needed. ## Filing bugs for assistive technologies -If the bug is related to a non-browser software, such as a screen reader, you need to file the bug with the relevant software vendor. The table below lists some of the most popular assistive technologies and where to file bugs for them. +If the bug is related to non-browser software, such as a screen reader, you need to file the bug with the relevant software vendor. The table below lists some of the most popular assistive technologies and where to file bugs for them. | Software | Where to file | | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | From 8f3e4c55ed9c8c31f287da088b058a149e46407e Mon Sep 17 00:00:00 2001 From: Joshua Chen Date: Sat, 27 Sep 2025 16:39:30 -0400 Subject: [PATCH 4/8] Apply suggestions from code review Co-authored-by: Chris Mills --- .../web_mechanics/file_browser_bugs/index.md | 37 ++++++++++++++----- 1 file changed, 27 insertions(+), 10 deletions(-) diff --git a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md index af997c8a6701476..027d3d88af5a250 100644 --- a/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md +++ b/files/en-us/learn_web_development/howto/web_mechanics/file_browser_bugs/index.md @@ -9,9 +9,16 @@ Browsers are software, and software has bugs. Sometimes you may find that your c ## Whose bug is it? -Before filing a bug to the browser, you should make sure that the bug is real. It could be in one of four places: your code, the documentation, the browser, or the specification. Generally, the specification is the most credible source of all; browsers and documentation both follow the spec and can be wrong; your code... well, the quality depends on you. +Before filing a browser bug, you should make sure that the bug is real. It could be in one of four places: your code, the documentation, the browser, or the specification. Generally, the specification is the most credible source of all; browsers and documentation both follow the spec and can be wrong. As for your code...well, the quality depends on you. -The first step is to extract a minimal test case that reproduces the bug. It should be small and standalone, preferably a single HTML file with embedded CSS and JavaScript, without external dependencies or unrelated code. This is useful for two reasons: it minimizes the possibility that the problem is in your own code, and you need to provide one anyway if you want to discuss it with anyone, including filing a bug. For example, the following would be a good test case for a bug related to the {{cssxref(":autofill")}} pseudo-class. Note how we stripped it down to the bare minimum, which means foregoing some best practices like the doctype, `` and `` tags, labels for inputs, etc. But that's okay, because the relevant code is still there. +### Creating a test case + +The first step is to extract a minimal test case that reproduces the bug. It should be small and standalone, preferably a single HTML file with embedded CSS and JavaScript, without external dependencies or unrelated code. This is useful for two reasons: + +1. It minimizes the possibility that the problem is caused by your own code or an external dependency. +2. You need to provide one anyway if you want to discuss it with anyone—for example, when filing a bug. + +For example, the following would be a good test case for a bug related to the {{cssxref(":autofill")}} pseudo-class. Note how we've stripped it down to the bare minimum, which means foregoing best practices like including the doctype, `` and `` tags, labels for inputs, etc. But that's okay, because the relevant code is still there. ```html