I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS: `arc patch --nobranch D111684`. 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menuitem.click()` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects submenus open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
Bug 1700724 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS: `arc patch --nobranch D111684`. 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menuitem.click()` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects submenus open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull central && hg up central && hg pull -r f87f844a6cc1f99edf46841f39284fea05a06a64 https://hg.mozilla.org/try/ && hg rebase -s eaa5adeadfd94d4fcbab6815e41f3389cabe9b8d -d . && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menuitem.click()` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects submenus open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull -r f87f844a6cc1f99edf46841f39284fea05a06a64 https://hg.mozilla.org/try/ && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menuitem.click()` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects submenus open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull -r f87f844a6cc1f99edf46841f39284fea05a06a64 https://hg.mozilla.org/try/ && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menuitem.click()` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects a submenu's open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull -r 8be3c755d73bfe361bf98a0091a666d7faa5fd4a https://hg.mozilla.org/try/ && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menu.activateItem(menuitem)` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects a submenu's open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull -r c44fd256b06c06c2a0da68e480da1382ad011ae4 https://hg.mozilla.org/try/ && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menu.activateItem(menuitem)` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects a submenu's open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.
I am asking for help with the remaining test failures. If you want to help, please proceed as follows: 1. Apply the current patch stack (currently going up to [D111684](https://phabricator.services.mozilla.com/D111684)) locally on macOS. The most reliable way to do this seems to be via the tryserver: `hg pull -r 72cb117f99f8a32f1d7e96dd91dd388b4ea352f0 https://hg.mozilla.org/try/ && hg up tip` 2. Build. 3. Select a row without an assignee in [this spreadsheet](https://docs.google.com/spreadsheets/d/13DIfZq7WbDvCipwmFOt9RGYyWuhVIrC96RPuZe9IfPY/edit#gid=0). 4. Put your name in the assignee column. 5. Confirm the test passes locally with non-native menus: `./mach mochitest testpath`. If it doesn't, ping me. 6. Run the test locally with native menus: `./mach mochitest testpath --setpref widget.macos.native-context-menus=true` 7. If it passes, mark the row as "Green with current patch stack: Yes" and go to step 3. 8. If it fails, find out why. Backchannel is #macdev on Matrix. So far, I've seen the following reasons for failures: 1. The test synthesizes mouse clicks on menu items to activate them (bug 1704211). Remedy: Tweak the test to call `menu.activateItem(menuitem)` instead. See the patches in bug 1704569 for many examples. 2. The test synthesizes mouse clicks on a menu item with a submenu to open the submenu. Remedy: Tweak the test to call `menu.openMenu(true)` instead. See the patches in bug 1704569 for many examples. 3. The test assumes certain popup events to be synchronous. Remedy: Listen for popupshown / popuphidden events as necessary. See bug 1704572 for some examples. 4. The test synthesizes an ESC key event to close a menu. Remedy: Tweak the test to call `menupopup.hidePopup()` instead. 5. The test checks menu implementation details that cannot be checked with native menus. Remedy: Turn off that part of the test if `widget.macos.native-context-menus` is `true`. 6. The test expects a submenu's open/close state to be reflected in submenupopup.state. This is bug 1704554 and I don't currently have a patch for it. Remedy: Set `widget.macos.native-context-menus` is `false` during the test, as a temporary workaround. To find the cause for the test failure, I've used the following approach: 1. Open the test JS file in your editor and search for "contextmenu". If found, see if the test calls `EventUtils.synthesizeMouseAtCenter` for elements inside the menu. If it does, you probably have failure scenarios 1 or 2. Try the simple replacements and see if the test passes now. Also make sure that the test still passes with non-native menus. 2. If the failure cause isn't immediately obvious, use the profiler to compare a good run with a bad run. Run `./mach mochitest testpath --profiler` to obtain a profile for the good run, and `./mach mochitest testpath --profiler --setpref widget.macos.native-context-menus=true` to obtain a profile of the bad run. You may need to manually quit the browser during the bad run. Now go to the marker chart of the parent process main thread and look for "popup"-related DOMEvents, and use the markers in the "Test" category (scroll down) to orient yourself.