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

Issue 795940 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Noscript Previews: on Facebook, pressing "Show original" in the infobar just reloads the Noscript version of the page.

Project Member Reported by sclit...@chromium.org, Dec 18 2017

Issue description

Chrome Version: 64.0.3282.29 (dev channel)
OS: Android

What steps will reproduce the problem?
(1) Make sure Noscript previews are enabled, Data Saver is enabled, and force the effective connection type to 2G.
(2) Load facebook.com in the browser. This seems to trigger a redirect to the noscript version of the site, mbasic.facebook.com/home.php.
(3) Click "Show original" in the infobar.

What is the expected result?

The fully-featured mobile Facebook site, e.g. m.facebook.com, loads in.

What happens instead?

The noscript version of the site reloads, and the infobar disappears. I'm still looking at the noscript experience. Note that the URL is still mbasic.facebook.com/home.php.

Please use labels and text to provide additional information.


For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.

 
Cc: sophiechang@chromium.org dougarnett@chromium.org manisca...@chromium.org aposner@chromium.org
Owner: bengr@chromium.org
Should "Load original" use the original navigation URL rather than the committed URL? That may only work for one level of navigation though. Once you are in the publisher's alternative experience, you might be too far in to load the comparable original subpage.

Raising issue to bengr for discussion.

[Note: this is an interesting issue for a URL redirection intervention as well.]


Interesting note: I went through these steps several times to see which host would be blacklisted, and (according to interventions-internals) I found that www.facebook.com ended up getting blacklisted, not mbasic.facebook.com.

This is a good thing, but odd, since somehow the infobar blacklisted "www.facebook.com" instead of "mbasic.facebook.com", even though clicking it reloads the "mbasic.facebook.com" version of the page.

Comment 3 by bengr@chromium.org, Dec 19 2017

Labels: Target-66
Owner: dougarnett@chromium.org
Status: Started (was: Assigned)
Did some investigation:

The PreviewsInfoBarDelegate requests the reload without specifying the URL via
NavigationController::Reload(ReloadType::DISABLE_PREVIEWS). As it stands, the
controller uses the last committed URL. My current idea is to replace the 
current navigation entry with a new entry that has the original requested URL
for the DISABLE_PREVIES reload type.

I prototyped this and it seems to work for the NoScript on facebook.com
scenario. Note that for LoFi, PreviewsInfoBarDelegate takes a different path
(ReloadLoFiImages).
Project Member

Comment 5 by bugdroid1@chromium.org, Jan 31 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6520278fc290bd6ef70fabbf788bac28c359c366

commit 6520278fc290bd6ef70fabbf788bac28c359c366
Author: Doug Arnett <dougarnett@chromium.org>
Date: Wed Jan 31 16:35:01 2018

Uses original request URL for ReloadType::DISABLE_PREVIEWS

When the user is viewing a preview page and selects "Show original",
the client asks the NavigationController to Reload(DISABLE_PREVIEWS).
It currently reloads the last committed URL which is a problem if
the preview caused a client redirect to occur so that the last
committed URL is a preview-specific URL. Really, we want to reload
the original requested URL to show the original page.

This CL updates the NavigatorImpl::NavigateToEntry() logic to use
the original request URL for ReloadType::DISABLE_PREVIEWS just as it
currently does for ReloadType::ORIGINAL_REQUEST_URL.

Bug:  795940 
Change-Id: Ic167afa48dca9e40eac3f0dabaf0fb5c5b6ddcdc
Reviewed-on: https://chromium-review.googlesource.com/879026
Commit-Queue: Doug Arnett <dougarnett@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533293}
[modify] https://crrev.com/6520278fc290bd6ef70fabbf788bac28c359c366/content/browser/frame_host/navigation_controller_impl_browsertest.cc
[modify] https://crrev.com/6520278fc290bd6ef70fabbf788bac28c359c366/content/browser/frame_host/navigation_controller_impl_unittest.cc
[modify] https://crrev.com/6520278fc290bd6ef70fabbf788bac28c359c366/content/browser/frame_host/navigator_impl.cc

Status: Fixed (was: Started)

Sign in to add a comment