1217769 - Cannot go back a page from "about:debugging" page

Status: VERIFIED FIXED

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

Description

[magicp]

Attachment: Cannot-go-back-a-page-from-about-debegging-page.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151021030212

Steps to reproduce:

1. Run Nightly 44.0a1
2. Open "about:about"
3. Click "about:debugging" link
4. Click Back button

Please refer to attached movie.


Actual results:

Cannot go back a page from "about:debugging" page.


Expected results:

Can go back a page from "about:debugging" page.

Comment 1

[magicp]

Reproduce on OS X, Ubuntu and Windows.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Looks like the about:about history entry is still there, but upon visiting about:debugging, an entry to about:debugging#addons is pushed onto the browsing history.

When the user hits back, we must hit the same script that re-injects about:debugging#addons. So the user is stuck there unless they click and hold the back button to go back to about:about.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Does seem to be document navigation bug, but an issue in about:debugging itself.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

er, does _not_ seem to be document navigation issue...

Comment 5

[Jan Keromnes [:janx]]

Agreed, this behavior is annoying.

We should probably make it so that the initial change from about:debugging to about:debugging#addons doesn't push onto the browsing history, e.g. with something like `window.history.replaceState()`.

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: bug1217769.v1.patch

Jan: I think we should make sure that the displayed view is in sync with the url hash. I would not like "addons" to be displayed if the URL bar contains "about:debugging#whatever". Using window.history.replaceState  That being said, It's fine to have the "addons" view mapped to both "about:debugging" and "about:debugging#addons".

(I tried playing with replaceState here, but didn't manage to get the behavior I wanted. If you have an implementation in mind, feel free to override this patch and submit another one.)

FYI: we still trap the navigation history if the user enters a wrong hash. I think this is a minor issue, but I see two potential solutions here:
- we could either display an error view
- we say we don't care about having the URL in sync with the view: we display the default tab even if the hash matches no valid tab

Comment 7

[Jan Keromnes [:janx]]

Comment on attachment 8745979 [details] [diff] [review]
bug1217769.v1.patch

Review of attachment 8745979 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, thanks for the quick fix!

(In reply to Julian Descottes [:jdescottes] from comment #6)
> Jan: I think we should make sure that the displayed view is in sync with the
> url hash. I would not like "addons" to be displayed if the URL bar contains
> "about:debugging#whatever".

Agreed, this would be confusing.

> That being
> said, It's fine to have the "addons" view mapped to both "about:debugging"
> and "about:debugging#addons".

That sounds fair.

> (I tried playing with replaceState here, but didn't manage to get the
> behavior I wanted. If you have an implementation in mind, feel free to
> override this patch and submit another one.)

That's OK, I like the behavior you implemented.

> FYI: we still trap the navigation history if the user enters a wrong hash. I
> think this is a minor issue, but I see two potential solutions here:
> - we could either display an error view
> - we say we don't care about having the URL in sync with the view: we
> display the default tab even if the hash matches no valid tab

I agree that it's a minor issue, but I do like your first follow-up suggestion. Would you mind opening another bug for it? Feel free to take it as well, or mark it [good-taipei-bug].

Comment 8

[Julian Descottes [:jdescottes]]

Thanks for the review. Just created the follow up Bug 1217769.

Try : https://treeherder.mozilla.org/#/jobs?repo=try&revision=09194ac3093f

Comment 9

[Pulsebot]

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

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f1ff46a78fa5

Comment 11

[Forhad Hossain]

I have reproduced the bug in Nightly 44.0a1 (2015-10-23)(Build ID:20151023030245) with the instruction from comment 0 and linux 64 bit

Bug is fixed now on latest Developer Edition 49.0a2 (2016-06-25)(Build ID:20160625004039)
User Agent:Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

[testday-20160624]