1268107 - Cannot use back in about:debugging after entering an invalid hash

Status: RESOLVED FIXED

(DevTools :: about:debugging, defect, P3)

Description

[Julian Descottes [:jdescottes]]

We force a navigation to "#addons" when an invalid hash is passed to "about:debugging".

STRs:
- go to "about:debugging"
- go to "about:debugging#invalid"
- press back

AR: Even when pressing back several times, the user remains on "about:debugging#addons"
ER: User should be able to go back to "about:debugging" and previous history states before that

To fix this, a possible solution is to stop redirecting to "#addons" but instead display an error page ("This address/category in invalid"). Or find a way to rewrite history states correctly using history.pushState()/replaceState().

The displayed view should always be in sync with the hash though -> we should not display the "addons" view if the url reads "about:debugging#someInvalidHash".

Comment 1

[Julian Descottes [:jdescottes]]

Follow up to Bug 1217769

Comment 2

[Jan Keromnes [:janx]]

Thank you Julian for filing this bug.

(In reply to Julian Descottes [:jdescottes] from comment #0)
> To fix this, a possible solution is to stop redirecting to "#addons" but
> instead display an error page ("This address/category in invalid"). Or find
> a way to rewrite history states correctly using
> history.pushState()/replaceState().

I think I prefer an error page, because if you navigate to "#addons" on a Runtime that doesn't support Add-ons, we should indicate this instead of transparently redirecting the user to something else (like "#tabs", which could be confusing).

Comment 3

[Jan Keromnes [:janx]]

Julian, would you be interested in mentoring this bug? If so, please set the "mentor" field on yourself.

Comment 4

[Julian Descottes [:jdescottes]]

Sure, done!

Comment 5

[Ricky Chien [:rickychien] (inactive)]

Hi Julian, I'd like to take this bug :)
Investigations and progress will be updated soon.

Comment 6

[Ricky Chien [:rickychien] (inactive)]

I'm favor of an error page just like janx mentioned on comment 2. I'm going to write a simple page with an error message when user enters #invalidURL

Comment 7

[Julian Descottes [:jdescottes]]

(In reply to Ricky Chien [:rickychien] from comment #5)
> Hi Julian, I'd like to take this bug :)
> Investigations and progress will be updated soon.

Great Ricky, thanks for picking this up! Let me know if you need help with about:debugging or with the devtools in general!

(In reply to Ricky Chien [:rickychien] from comment #6)
> I'm favor of an error page just like janx mentioned on comment 2. I'm going
> to write a simple page with an error message when user enters #invalidURL

Perfect, in favor of this one as well.

Comment 8

[Ricky Chien [:rickychien] (inactive)]

Attachment: MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review commit: https://reviewboard.mozilla.org/r/51919/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/51919/

Comment 9

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/51919/diff/1-2/

Comment 10

[Ricky Chien [:rickychien] (inactive)]

This patch just put "Page not found" on the screen when user navigates in a #invalid url. And it also do a small refactor to remove panelId that makes code more readable (feel free to discuss this part :))

I noticed that when I trigger an invalid url and at the same time focusing on a tab (ex: focusing on worker tab and entering an invalid url). Weird thing happened and my invalid hash was reseted since there is an onKeyUp event in panel-menu-entry.js which triggered hash change again.

I prefer to disable it and but I'd like to hear you opinion about this :)

Comment 11

[Ricky Chien [:rickychien] (inactive)]

I also notice that I can't see the default hash #addons appends on browser's url bar when I first time visit to about:debugging (first time launch firefox and then visit about:debugging).

Comment 12

[Julian Descottes [:jdescottes]]

https://reviewboard.mozilla.org/r/51919/#review48755

Thanks for the patch, this is a good start!
Please have a look at my comments below and let me know if anything is unclear.

On a sidenote, you can run ./mach test devtools/client/aboutdebugging/test to run the aboutdebugging tests. 
The current patch is making some of them fail. (addressing my issues below should solve it though).

We will also need to look at adding a test here, but we can do that in a second step.

::: devtools/client/aboutdebugging/components/aboutdebugging.js:6
(Diff revision 2)
>  /* This Source Code Form is subject to the terms of the Mozilla Public
>   * License, v. 2.0. If a copy of the MPL was not distributed with this
>   * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
>  
>  /* eslint-env browser */
> -/* globals AddonsPanel, WorkersPanel */
> +/* globals AddonsPanel, TabsPanel, WorkersPanel, PageNotFoundPanel */

nit: We can actually remove this comment, our eslint rules are now capable to pick up properties added to the global object using 

loader.lazyGetter(this, "AddonsPanel",
  () => createFactory(require("./addons/panel")));

::: devtools/client/aboutdebugging/components/aboutdebugging.js:22
(Diff revision 2)
>    () => createFactory(require("./addons/panel")));
>  loader.lazyGetter(this, "TabsPanel",
>    () => createFactory(require("./tabs/panel")));
>  loader.lazyGetter(this, "WorkersPanel",
>    () => createFactory(require("./workers/panel")));
> +loader.lazyGetter(this, "PageNotFoundPanel",

(if we keep this as a Panel)

In aboutdebugging, we tried to sort all imports alphabetically, so this should move between AddonsPanel and TabsPanel :)

::: devtools/client/aboutdebugging/components/aboutdebugging.js
(Diff revision 2)
>  const Strings = Services.strings.createBundle(
>    "chrome://devtools/locale/aboutdebugging.properties");
>  
>  const panels = [{
>    id: "addons",
> -  panelId: "addons-panel",

Not sure changing the id/panelId logic should be done here. 
Even though I agree we could simplify here, I would prefer to have this in a separate bug and discuss it.

::: devtools/client/aboutdebugging/components/aboutdebugging.js:63
(Diff revision 2)
>      };
>    },
>  
>    componentDidMount() {
>      window.addEventListener("hashchange", this.onHashChange);
> -    this.onHashChange();
> +    this.selectPanel(defaultPanelId);

This triggers a mandatory navigation to the default panel when starting the component.
This is an issue for the following scenario:
- open a new tab
- type "about:debugging#workers" in the URL bar, press ENTER

ER : The URL should remain "about:debugging#workers", the workers panel should be displayed
AR : The browser navigates to "about:debugging#addons", addons panel is displayed

::: devtools/client/aboutdebugging/components/aboutdebugging.js:76
(Diff revision 2)
>    },
>  
>    onHashChange() {
> -    let hash = window.location.hash;
> -    // Default to defaultTabId if no hash is provided.
> -    let panelId = hash ? hash.substr(1) : defaultPanelId;
> +    this.setState({
> +      selectedPanelId: window.location.hash.substr(1)
> +    });

The URL "about:debugging" (with no hash) should remain a valid landing point, and should display the "addons" panel.
That's why we were defaulting to "defaultPanelId" here.

STRs:
1. open any page
2. navigate to "about:debugging"

ER : The URL should remain "about:debugging"
AR : The browser navigates to "about:debugging#addons"

3. press BACK 

ER : You should go back to the page of step 1.
AR : The browser goes back to "about:debugging" and the error panel is displayed.

::: devtools/client/aboutdebugging/components/moz.build:9
(Diff revision 2)
>  
>  DIRS += [
>      'addons',
>      'tabs',
>      'workers',
> +    'page-not-found',

(if we keep this as a separate panel): sort alphabetically

::: devtools/client/aboutdebugging/components/page-not-found/panel.js:11
(Diff revision 2)
> +
> +const { createClass, DOM: dom } =
> +  require("devtools/client/shared/vendor/react");
> +
> +module.exports = createClass({
> +  displayName: "PageNotFound",

(if we keep this as a separate panel) 

The displayName should be PageNotFoundPanel, to be consistent with the addons and workers panel components.

::: devtools/client/aboutdebugging/components/page-not-found/panel.js:14
(Diff revision 2)
> +
> +module.exports = createClass({
> +  displayName: "PageNotFound",
> +
> +  render() {
> +    return dom.div({ className: "page-not-found" },

For now the error page is simply displaying a static message. 

Maybe we can start without a dedicated component. We could create this element directly in aboutdebugging.js' render method. What do you think?

If in the future it becomes more complex, we will of course extract it.

::: devtools/client/aboutdebugging/components/page-not-found/panel.js:15
(Diff revision 2)
> +module.exports = createClass({
> +  displayName: "PageNotFound",
> +
> +  render() {
> +    return dom.div({ className: "page-not-found" },
> +      dom.h1({ className: "header-name" }, "Page not found")

We need to retrieve the localized version of the string. 

> const Strings = Services.strings.createBundle(
>   "chrome://devtools/locale/aboutdebugging.properties");
>   
> [...]
>
> Strings.GetStringFromName("pageNotFound")
> 

You can look at components/target-list.js for an example.

::: devtools/client/aboutdebugging/components/panel-menu-entry.js:18
(Diff revision 2)
>    onClick() {
>      this.props.selectPanel(this.props.id);
>    },
>  
>    onKeyUp(event) {
> -    if ([" ", "Enter"].includes(event.key)) {
> +    if (event.key === " ") {

There is indeed an issue when focusing an element of the menu, then editing the URL bar and pressing enter.

I think that for accessibility reasons, we should keep this mapped to both SPACE and ENTER keys.

How about remapping this event listener to "keypress" instead of keyup?

Comment 13

[Julian Descottes [:jdescottes]]

Attachment: page-not-found-panel.png

Helen: This is a screenshot of "about:debugging" when a user enters an invalid hash (such as about:debugging#wrokers)

Is "Page not found" fine in this context? Should we display something more specific to aboutdebugging ("Unknown category %s")?

Comment 14

[Julian Descottes [:jdescottes]]

(In reply to Ricky Chien [:rickychien] from comment #11)
> I also notice that I can't see the default hash #addons appends on browser's
> url bar when I first time visit to about:debugging (first time launch
> firefox and then visit about:debugging).

I missed this comment, sorry! This is the intended behavior. I mentioned it on the fly in the review but here are some more details.

The current situation is :
- "about:debugging" -> no additional navigation, displays the addons panel
- "about:debugging#a-valid-hash" -> no additional navigation, displays the corresponding panel
- "about:debugging#invalid-hash" -> navigates to "about:debugging#addons"

The goal of this bug is to improve the "invalid-hash" use case on two fronts:
- let the user know the hash/category was invalid (rather than silently redirecting)
- allow the user to use BACK after typing an invalid hash (today, using BACK just keeps the user looping between the invalid hash and the default hash)

I should have added this information in the summary. Sorry about that!

Comment 15

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: page-not-found-panel-2.png

(In reply to Julian Descottes [:jdescottes] from comment #13)
> Created attachment 8751357 [details]
> page-not-found-panel.png
> 
> Helen: This is a screenshot of "about:debugging" when a user enters an
> invalid hash (such as about:debugging#wrokers)
> 
> Is "Page not found" fine in this context? Should we display something more
> specific to aboutdebugging ("Unknown category %s")?

"Page not found" seems like a reasonable error—is this a 404, in essence?

I think it might be nice to have a small, gray, underlined link with "Show more details" that would expand and show the specific to about:debugging error ("Unknown category %s").

Comment 16

[Ricky Chien [:rickychien] (inactive)]

https://reviewboard.mozilla.org/r/51919/#review48755

> For now the error page is simply displaying a static message. 
> 
> Maybe we can start without a dedicated component. We could create this element directly in aboutdebugging.js' render method. What do you think?
> 
> If in the future it becomes more complex, we will of course extract it.

Agree!

> There is indeed an issue when focusing an element of the menu, then editing the URL bar and pressing enter.
> 
> I think that for accessibility reasons, we should keep this mapped to both SPACE and ENTER keys.
> 
> How about remapping this event listener to "keypress" instead of keyup?

Yeah, I can understand that the purpose of bind SPACE and ENTER as accessiblity reason.

As comment 10 mentioned, I found there was a weird behavior if we focus on a tab and type a #invalid url. It will not enter #invalid url with a page-not-found page but still remain in that tab instead. However, listener to onKeyDown works as expected.

Comment 17

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/51919/diff/2-3/

Comment 18

[Ricky Chien [:rickychien] (inactive)]

I haven't look into previous test failures but these failures gone after my patch updated.

Comment 19

[Ricky Chien [:rickychien] (inactive)]

Write down a bug I just noticed:

STR:

1. open a website.
2. visit about:debugging#workers
3. Try to use tab key to select "Add-ons" panel and press enter or space

ER: url will change to about:debugging#add-ons.
AR: url remain at about:debugging#workers but add-ons panel appears correctly.

However, try to console.log(window.location.hash) will show up correct url about:debugging#add-ons.
window.location.hash is inconsistent with browser url.

Julian, do you know what's going on?

Comment 20

[Julian Descottes [:jdescottes]]

(In reply to Ricky Chien [:rickychien] from comment #19)
> Write down a bug I just noticed:
> 
> STR:
> 
> 1. open a website.
> 2. visit about:debugging#workers
> 3. Try to use tab key to select "Add-ons" panel and press enter or space
> 
> ER: url will change to about:debugging#add-ons.
> AR: url remain at about:debugging#workers but add-ons panel appears
> correctly.
> 
> However, try to console.log(window.location.hash) will show up correct url
> about:debugging#add-ons.
> window.location.hash is inconsistent with browser url.
> 
> Julian, do you know what's going on?

Good find! You don't have to navigate using SPACE/ENTER. Simply clicking the link will trigger the same issue. 

Not related to your change though, running through mozregression to find the origin at the moment. I doubt the issue comes from about:debugging. Let's ignore this for now.

Comment 21

[Julian Descottes [:jdescottes]]

Thanks for the feedback Helen!

(In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #15)
> Created attachment 8751424 [details]
> page-not-found-panel-2.png
> 

I think this is the same screenshot as mine, did you intend to upload something else?

> (In reply to Julian Descottes [:jdescottes] from comment #13)
> > Created attachment 8751357 [details]
> > page-not-found-panel.png
> > 
> > Helen: This is a screenshot of "about:debugging" when a user enters an
> > invalid hash (such as about:debugging#wrokers)
> > 
> > Is "Page not found" fine in this context? Should we display something more
> > specific to aboutdebugging ("Unknown category %s")?
> 
> "Page not found" seems like a reasonable error—is this a 404, in essence?
> 

I guess it is: we navigate to a URL, for which we can't display anything. My first reaction was that "page" could be confusing, in my mind about:debugging is the page.

>
> I think it might be nice to have a small, gray, underlined link with "Show
> more details" that would expand and show the specific to about:debugging
> error ("Unknown category %s").

Sounds good, we will either implement this here or in a follow-up.

Comment 22

[Julian Descottes [:jdescottes]]

(In reply to Julian Descottes [:jdescottes] from comment #21)
> > 
> > "Page not found" seems like a reasonable error—is this a 404, in essence?
> > 
> 
> I guess it is: we navigate to a URL, for which we can't display anything. My
> first reaction was that "page" could be confusing, in my mind
> about:debugging is the page.
> 

And of course I forgot to clarify: totally fine with keeping the current label.

Comment 23

[Julian Descottes [:jdescottes]]

https://reviewboard.mozilla.org/r/51919/#review49105

Looks good, thanks for quickly coming up with a new patch. 
Let's add a test and we will land this.

By the way, mozreview is not able to pick my name as reviewer from your commit message. Maybe there is something I should do?
Otherwise I know r=jdescottes works :)

::: devtools/client/aboutdebugging/components/aboutdebugging.js:85
(Diff revision 3)
>      let selectPanel = this.selectPanel;
> -
>      let selectedPanel = panels.find(p => p.id == selectedPanelId);
>  
> +    if (selectedPanel) {
> +      selectedPanel = selectedPanel.component({ client, id: selectedPanel.id });

nit: selectedPanel is a "panel" object and should not be reassigned to a react component. Let's introduce another variable here.

Comment 24

[Julian Descottes [:jdescottes]]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

As I said, let's try to add a new test! One flow that could be tested for example:
1. open about:debugging on "invalid-hash" (you can use openAboutDebugging("invalid-hash") and check we are on the error page 
2. click on the addons menu item
  - You could do it by simulating a click as follows: document.querySelector("[aria-controls=\"addons-panel\"]").click(); 
  - maybe a good opportunity for a small helper method in aboutdebugging/test/head.js
3. Wait for the navigation to occur:
  - waitForMutation(document.querySelector(".main-content"), {childList: true}) should work here 
4. Wait for the addons page to be loaded 
5. Navigate to the error page, check the error page is displayed
6. Navigate back to #addons
7. Navigate back to the first error page

Let me know if you have any question! You can also have a look at Helen's UI proposition. Would you be interested in implementing this? We can either do it here or in a follow up Bug.

Comment 25

[Helen V. Holmes (:helenvholmes) (:✨)]

Attachment: page-not-found-panel-2.png

(In reply to Julian Descottes [:jdescottes] from comment #21)
> Thanks for the feedback Helen!
> 
> (In reply to Helen V. Holmes (:helenvholmes) (:✨)(pls ni?) from comment #15)
> > Created attachment 8751424 [details]
> > page-not-found-panel-2.png
> > 
> 
> I think this is the same screenshot as mine, did you intend to upload
> something else?
Oh goodness, I'm sorry—this was what I meant!

> > (In reply to Julian Descottes [:jdescottes] from comment #13)
> > "Page not found" seems like a reasonable error—is this a 404, in essence?
> > 
> 
> I guess it is: we navigate to a URL, for which we can't display anything. My
> first reaction was that "page" could be confusing, in my mind
> about:debugging is the page.
In my head I've played around with "hash not found", "url not found"—I think that "Page not found", which technically incorrect, is probably the best way to go. (It's just the most obvious.)

Comment 26

[Helen V. Holmes (:helenvholmes) (:✨)]

Comment on attachment 8751357 [details]
page-not-found-panel.png

Clearing my review, everything looks good to me (see attachment page-not-found-panel-2.png for follow-up work)

Comment 27

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/51919/diff/3-4/

Comment 28

[Ricky Chien [:rickychien] (inactive)]

I ended up figured out the way to do automatic testing for the test case, some of APIs are not so straightforward to me though. I found out openUILinkIn() can reset my url properly since window.location is unable to be used here.

Comment 29

[Ricky Chien [:rickychien] (inactive)]

(In reply to Julian Descottes [:jdescottes] from comment #24)
> Let me know if you have any question! You can also have a look at Helen's UI
> proposition. Would you be interested in implementing this? We can either do
> it here or in a follow up Bug.

Sure! follow up bug will be picked up once this issue is fixed.

Comment 30

[Julian Descottes [:jdescottes]]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

https://reviewboard.mozilla.org/r/51919/#review49674

Great work! 
There's a leftover issue from the previous review and a few nits but I don't think we need another review cycle.
Also I really think you need to update the commit message to end with r=jdescottes the "r?:jdescottes" seems to be problematic. 

Let's get this through try before landing as well (let me know if you need help with that).

Thanks again!

::: devtools/client/aboutdebugging/components/aboutdebugging.js:84
(Diff revisions 2 - 4)
>      let { client } = this.props;
>      let { selectedPanelId } = this.state;
>      let selectPanel = this.selectPanel;
> -    let selectedPanel = panels.find(p => p.id == selectedPanelId) ||
> -        pageNotFound;
> +    let selectedPanel = panels.find(p => p.id == selectedPanelId);
> +
> +    if (selectedPanel) {

Already mentioned in the previous review: we need another variable here: selectedPanel should not switch from a panel object to a react component.

::: devtools/client/aboutdebugging/test/.eslintrc:17
(Diff revision 4)
>      "getServiceWorkerList": true,
>      "getSupportsFile": true,
>      "installAddon": true,
>      "openAboutDebugging": true,
> +    "openPanel": true,
> +    "openUILinkIn": true,

Only head.js uses openUILinkIn, no need to declare it here. 
If we want it as a global in head.js, we can declare it in the same way as "sendAsyncMessage" (in head.js line 10). Or we can use window.openUILinkIn as I suggest below.

Also I don't believe we need to keep this list, globals from head.js are now automatically picked up by eslint and made available in tests. I will file a follow up to clean this up.

::: devtools/client/aboutdebugging/test/browser.ini:26
(Diff revision 4)
>  [browser_service_workers_start.js]
>  [browser_service_workers_timeout.js]
>  skip-if = true # Bug 1232931
>  [browser_service_workers_unregister.js]
>  [browser_tabs.js]
> +[browser_page_not_found.js]

nit: Can you sort this alphabetically?

::: devtools/client/aboutdebugging/test/browser_page_not_found.js:1
(Diff revision 4)
> +/* Any copyright is dedicated to the Public Domain.

Great test, thanks!

::: devtools/client/aboutdebugging/test/browser_page_not_found.js:4
(Diff revision 4)
> +/* Any copyright is dedicated to the Public Domain.
> +   http://creativecommons.org/publicdomain/zero/1.0/ */
> +"use strict";
> +

Add a comment describing what is being tested

::: devtools/client/aboutdebugging/test/browser_page_not_found.js:11
(Diff revision 4)
> +  let { tab, document } = yield openAboutDebugging("invalid-hash");
> +  let element = document.querySelector(".header-name");
> +  is(element.textContent, "Page not found", "Show error page");
> +
> +  yield openPanel(document, "addons-panel");
> +  element = document.querySelector(".header-name");

When navigating to "addons", let's wait for 

yield waitForInitialAddonList(document);

to make sure we don't have any pending call before continuing the test and navigating to another page.

::: devtools/client/aboutdebugging/test/browser_page_not_found.js:20
(Diff revision 4)
> +  element = document.querySelector(".header-name");
> +  is(element.textContent, "Page not found", "Show error page");
> +
> +  gBrowser.goBack();
> +  yield waitForMutation(
> +    document.querySelector(".main-content"), {childList: true});

Same as above, let's wait on 
yield waitForInitialAddonList(document);

::: devtools/client/aboutdebugging/test/head.js:9
(Diff revision 4)
>  /* eslint-env browser */
>  /* eslint-disable mozilla/no-cpows-in-tests */
> -/* exported openAboutDebugging, closeAboutDebugging, installAddon,
> -   uninstallAddon, waitForMutation, assertHasTarget, getServiceWorkerList,
> -   getTabList, waitForInitialAddonList, waitForServiceWorkerRegistered,
> -   unregisterServiceWorker */
> +/* exported openAboutDebugging, changeAboutDebuggingHash, closeAboutDebugging,
> +   installAddon, uninstallAddon, waitForMutation, assertHasTarget,
> +   getServiceWorkerList, getTabList, openPanel, waitForInitialAddonList,
> +   waitForServiceWorkerRegistered, openUILinkIn, unregisterServiceWorker */

This list is here to avoid warning about unused vars.
We never create "openUILinkIn" here so no need to export it.

::: devtools/client/aboutdebugging/test/head.js:46
(Diff revision 4)
>    }
>  
>    return { tab, document };
>  }
>  
> +function* changeAboutDebuggingHash(document, page) {

nit: Let's add JS doc here.
nit: A generator function is not mandatory here. Alternatively we can use a regular function and return waitForMutation.

::: devtools/client/aboutdebugging/test/head.js:47
(Diff revision 4)
>  
>    return { tab, document };
>  }
>  
> +function* changeAboutDebuggingHash(document, page) {
> +  info(`opening about:debugging#${page}`);

nit: most of our info logs are capitalized => s/opening/Opening

::: devtools/client/aboutdebugging/test/head.js:48
(Diff revision 4)
>    return { tab, document };
>  }
>  
> +function* changeAboutDebuggingHash(document, page) {
> +  info(`opening about:debugging#${page}`);
> +  openUILinkIn(`about:debugging#${page}`, "current");

I think you can use window.openUILinkIn here

::: devtools/client/aboutdebugging/test/head.js:53
(Diff revision 4)
> +  openUILinkIn(`about:debugging#${page}`, "current");
> +  yield waitForMutation(
> +    document.querySelector(".main-content"), {childList: true});
> +}
> +
> +function* openPanel(document, panelId) {

Same comments as for changeAboutDebuggingHash

Comment 31

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/51919/diff/4-5/

Comment 32

[Ricky Chien [:rickychien] (inactive)]

Comment on attachment 8751229 [details]
MozReview Request: Bug 1268107 - Cannot use back in about:debugging after entering an invalid hash r?jdescottes

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/51919/diff/5-6/

Comment 33

[Ricky Chien [:rickychien] (inactive)]

According to mozreview doc, set r=<reviewer> to specify reviewer, is not recommended. Mozreview will do this job automatically:)

Comment 34

[Ricky Chien [:rickychien] (inactive)]

Waiting for try.

Comment 35

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/808ee4a5e323

Comment 36

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/fx-team/rev/808ee4a5e323

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/808ee4a5e323

Comment 38

[Saheda Reza [:Antora]]

Reproduced this bug on Firefox nightly according to (2016-04-27)

Fixing bug is verified on Latest Developer Edition-- Build ID:(20160703004019 ),User Agent: Mozilla/5.0 (Windows NT 10.0; rv:49.0) Gecko/20100101 Firefox/49.0

Tested OS--Windows10 32bit