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

Issue 845716 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Make reload button on untrusted page to reload the file url

Project Member Reported by romax@chromium.org, May 22 2018

Issue description

It's currently reloading to online URL, which should not be the case for untrusted pages. It should reload the file.
 
Did the requirements change? This behavior was intentional.

Comment 2 by romax@chromium.org, May 22 2018

I'm copy-pasting the description from the Asana task:
"""
Note the refresh action (pullback or Refresh in main menu) should not go to the online.
Clicking Reload should cause a top-level navigation with empty referrer in the same tab to the URL requested by offline page.
"""

I think the 'should not go to the online' mean it should not load online url. But if there's any clarification it would be great.
Cc: aboss@chromium.org
From the PRD:
"If user has connectivity they see the reload snackbar and can refresh the page to navigate to the URL the page claims to be from."

go/offline-pages-p2p-prd 


Comment 4 by romax@chromium.org, May 23 2018

Cc: petewil@chromium.org dim...@chromium.org jianli@chromium.org
Thanks for the info from PRD. I think there was a related discussion on this and seems the conclusion (that it should reload the file:// or content://) conflicts with this, and the topic was around security reasons. I don't know if it had changed with the ability to parse original url from MHTML file.

Adding more people as I cannot remember what was the exact conclusion. I apologize if I remembered things wrong.

aboss@, can you please confirm?

Comment 5 by romax@chromium.org, May 31 2018

Status: WontFix (was: Started)
just got a reply from aboss@ that we're good to reload to the claimed online url. So we should stick with the PRD.

Thanks dewittj@ for pointing out! I'll abandon the related change and mark this bug as won't fix.

Sign in to add a comment