New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 602426 link

Starred by 4 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Unexpected navigation backwards in history on selecting "Request desktop site"

Reported by bmfail...@gmail.com, Apr 11 2016

Issue description

Chrome Version       : 49.0.2623.105 (AT&T Samsung S5)
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
    Safari: iPad Mini 2 running iOS 9.3.1 - OK
   Firefox: 45.0.1 (AT&T Samsung S5) - OK
        IE: N/A

What steps will reproduce the problem?

With all three of the attached files in the same directory and the browser history cleared, perform the following steps:
(1) navigate to the first file entitled “chromeRDSbug1.html” with title “Chrome RDS Test Page 1”
(2) touch “Open Menu” and touch on “RDS Test Page 2” (causing navigation to the second file entitled “chromeRDSbug2.html” with title “Chrome RDS Test Page 2”)
(3) touch “Open Menu” and touch on “RDS Test Page 3” (causing navigation to the third file entitled “chromeRDSbug3.html” with title “Chrome RDS Test Page 3”)
(4) open the Chrome menu and select “Request desktop site”

What is the expected result?

The browser should re-display the third file entitled “chromeRDSbug3.html” with title “Chrome RDS Test Page 3.”

What happens instead?

The browser instead displays the second file entitled “chromeRDSbug2.html” with title “Chrome RDS Test Page 2.”  In other words, it navigates backwards one page in the history on selecting "Request desktop site."

Please provide any additional information below. Attach a screenshot if
possible.

 
chromeRDSbug1.html
11.0 KB View Download
chromeRDSbug2.html
11.0 KB View Download
chromeRDSbug3.html
11.0 KB View Download
Labels: OS-Android

Comment 2 by b...@chromium.org, Apr 12 2016

Components: UI>Browser>Navigation
Cc: acindhe@chromium.org
Labels: triage-te
@bmfailing@gmail.com: Thanks filing bug. Could you please re-check latest chrome version "M51".

Comment 5 by bmfail...@gmail.com, Jun 22 2016

Same result.  Tested on AT&T Samsung S5 (Android 5.1.1, Chrome 51.0.2704.81).
Cc: -acindhe@chromium.org krav...@chromium.org
kravula@ could you please triage this bug from your end. Thanks 
Cc: msrchandra@chromium.org
Labels: Needs-triage-Mobile Needs-Feedback
@bmfailing -- Could you please re-check on Latest Stable# 62.0.3202.84 and let us know the latest behavior, if reproducible provide us with a screen cast which would help us triaging the issue further.
Thanks in Advance.
We've noticed the very same bug in our forums (https://www.computerbase.de/forum/) and I've been able to reproduce the issue using the test-case provided by @bmfailing in Chrome 62 and in Chrome Canary 64.0.3277.0.

@msrchandra: I've attached a screen cast.
Chrome Bug 602426.mp4
1.8 MB View Download
The bug disappears if you remove the click event handler from the test-case (such that the navigation is triggered by a standard link click).

If, however, the navigation is triggered via JavaScript by changing "window.location"  then "Request desktop site" causes the browser to navigate back.

I'm not sure why such a navigation seems to go unnoticed by RDS. Shouldn't "Request desktop site" just use the URL visible in the address bar?
Status: WontFix (was: Unconfirmed)
***Bulk Edit***

There is no valid investigation in the bug, closing. Feel free to reopen if needed.

Sign in to add a comment