Back Button Does Not Return User to Previously Viewed PDF File
Reported by
dfeinst...@srsd.org,
Jun 1 2016
|
|||||||||
Issue descriptionChrome Version : 51.0.2704.63 URLs (if applicable) : http://teachers.srsd.net/dkowalski/15-1-high-school-summer-reading/ Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: Firefox: OK, 46.0.1 IE: OK, 11.0.9600.16428 What steps will reproduce the problem? (1) Access http://teachers.srsd.net/dkowalski/15-1-high-school-summer-reading/ (2) Under the heading, "Required Reading for All Students:," click on the link, "10th Grade." (3) In the PDF file that loads, http://teachers.srsd.net/dkowalski/wp-content/uploads/2014/05/10th-Grade-The-Time-Keeper.pdf , click on the link - http://www.amazon.com/Time-Keeper-Mitch-Albom/dp/1401312853 . (4) Once the Amazon.com Web page - https://www.amazon.com/Time-Keeper-Mitch-Albom/dp/1401312853?ie=UTF8&*Version*=1&*entries*=0 - loads, click on the Back button. Google Chrome does not load the previously visited PDF file. What is the expected result? After clicking on the Back button, Google Chrome should load the PDF file - http://teachers.srsd.net/dkowalski/wp-content/uploads/2014/05/10th-Grade-The-Time-Keeper.pdf - that was previously visited before the Amazon.com Web page was loaded. What happens instead? Clicking on the Back button does not appear to cause any response in Google Chrome. The Amazon.com Web page - https://www.amazon.com/Time-Keeper-Mitch-Albom/dp/1401312853?ie=UTF8&*Version*=1&*entries*=0 - remains loaded. Please provide any additional information below. Attach a screenshot if possible. This process works as intended in Mozilla Firefox as evidenced by the screencast http://screencast.com/t/8PS4gYUQTcA . This process also works as intended in Internet Explorer.
,
Jun 3 2016
The latest version of Google Chrome, 51.0.2704.79, is installed. Clearing cookies and the browser history does not resolve the problem. In addition, using Incognito mode does not resolve the issue. This problem has been reproduced on two different computers, with two different Google accounts, using Windows 7. The following video demonstrates the problem: http://screencast.com/t/MyHZgl3njHA .
,
Jun 4 2016
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 6 2016
Just tried again on Win 7 for chrome stable version 51.0.2704.79, unable to reproduce it, tried on 4 different systems with win 7. Request you to please navigate to advanced section in chrome://settings and check to reset chrome. Please try this and update us with the behavior. Thanks.!
,
Jun 30 2016
Able to reproduce this on the latest stable(51.0.2704.106) and the latest M-52(52.0.2743.60) on Windows-7, Mac OS 10.11.5 and Linux Ubuntu 14.04. This is fixed in the latest M-53(53.0.2784.1) across all OS. Reverse bisected to find the CL that fixed this: Last bad build: 52.0.2743.60 First good build:53.0.2744.0 Changelog: https://chromium.googlesource.com/chromium/src/+log/56e86646b3dce1e3c60cc32e121e42ff4a4f6eb1..14d2940046d2bb1c52d615967a80bcd5f5e3e551 Suspected change that would have fixed this: https://codereview.chromium.org/1990343002 alexmos@: Could you please get the above CL merged to M-52 as well. Thank you!
,
Jun 30 2016
I've reproed this issue on stable and confirmed that my CL indeed fixes this. This was surprising to me, so I dug a bit more to understand what the problem was. What happens is: - clicking on the PDF link on the original page opens the PDF in a new tab in the same process. - clicking on the amazon link in the PDF navigates the new tab to a new process, and swaps out the PDF page's main frame to a remote frame in the old process. (Thanks to swapped out being gone on stable.) - clicking back invokes a check, canShowMIMEType() in DocumentLoader, while loading the main resource in the old process. - that check relies on pluginData(), which used to fail when the main frame was remote before my fix. So, requesting to merge my r394942 to M-52.
,
Jul 1 2016
Your change meets the bar and is auto-approved for M52 (branch: 2743)
,
Jul 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bc0578a78ae310a0216210e9e6894537acb7d8e6 commit bc0578a78ae310a0216210e9e6894537acb7d8e6 Author: Alex Moshchuk <alexmos@chromium.org> Date: Fri Jul 01 22:03:34 2016 Fix navigator.plugins and navigator.mimeTypes for OOPIFs. Previously, Page::pluginData() returned nullptr when the Page's main frame was a RemoteFrame. This caused navigator.plugins and navigator.mimeTypes to both return empty arrays from an OOPIF. Page::pluginData() needed the main frame to run the FrameLoader::allowPlugins check on it. This CL moves this check to happen on the actual LocalFrame that needs to access Page::pluginData(). BUG= 612200 , 607981 , 616445 Review-Url: https://codereview.chromium.org/1990343002 Cr-Commit-Position: refs/heads/master@{#394942} (cherry picked from commit fb92f3e718335521cf454e53651235fbf30c10e2) Review URL: https://codereview.chromium.org/2121433002 . Cr-Commit-Position: refs/branch-heads/2743@{#572} Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939} [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/LayoutTests/FlagExpectations/site-per-process [add] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/LayoutTests/http/tests/plugins/navigator-plugins-in-cross-origin-frame-expected.txt [add] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/LayoutTests/http/tests/plugins/navigator-plugins-in-cross-origin-frame.html [add] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/LayoutTests/http/tests/plugins/resources/navigator-plugins-frame.html [add] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/LayoutTests/http/tests/plugins/resources/navigator-plugins.js [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/dom/DOMImplementation.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/frame/LocalFrame.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/frame/LocalFrame.h [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/loader/DocumentLoader.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/core/page/Page.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/modules/plugins/DOMMimeTypeArray.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/modules/plugins/DOMPluginArray.cpp [modify] https://crrev.com/bc0578a78ae310a0216210e9e6894537acb7d8e6/third_party/WebKit/Source/web/FrameLoaderClientImpl.cpp
,
Jul 1 2016
M52 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on July 8th (in case if you missed today's 5:00 PM PST deadline) to make into the desktop Stable final build cut. Thank you!
,
Jul 5 2016
Tested this issue on Windows 7, Ubuntu 14.04 and Mac OS 10.11.5 using chrome latest M52-52.0.2743.67 by following steps mentioned in the original comment. Observed by clicking back button it returns to previously viewed PDF file as expected. Hence adding TE-Verified label.
,
Jul 6 2016
This should be fixed now. I noticed that when my merge went in, the stable builders started failing on some WebMediaPlayerMSTests in content_unittests, but it looks like that is an unrelated problem covered by issue 623217. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ranjitkan@chromium.org
, Jun 3 2016Labels: Needs-Feedback