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

Issue 654368 link

Starred by 2 users
Status: Assigned
Owner:
rdevlin....@chromium.org
Cc:
gov...@chromium.org
rob@robwu.nl
nyerramilli@chromium.org
pbomm...@chromium.org
█ brajkumar@chromium.org
█ tkonch...@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression : PDF tab closes and does not reopen after checking the ‘Allow in incognito’ checkbox of 'PDF-viewer' extension.

Reported by yfulgaon...@etouch.net, Oct 10 2016 
Chrome Version : 55.0.2883.6 (Official Build) 7baa26fcf5c0933d5718c621debbd5d380696639-refs/branch-heads/2883@{#11} (32/64-bit)
OS: Mac(10.10.5)(10.11.5), Windows(7,8,8.1,10), Linux(14.04 LTS)

Test URL 1. https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm?utm_source=chrome-ntp-icon
Test URL 2. chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf

What steps will reproduce the problem?
1. Launch chrome, navigate to Test URL 1 and add ‘PDF-viewer’ extension. 
2. Navigate to Test URL 2 and wait until PDF page loads completely.
3. Now in new tab, open chrome://extensions, scroll down the page and check the ‘Allow in incognito’ checkbox of ‘PDF-viewer’ extension.
4. Observe the PDF page.

Actual : PDF tab closes and does not reopen after checking the ‘Allow in incognito’ checkbox.
Expected : Instead, PDF tab should close and reopen automatically after checking the ‘Allow in incognito’ checkbox.

This is a regression issue broken in ‘M-55’, below is the Manual Regression and will soon update bisect info.
Good build : 55.0.2872.0
Bad build : 55.0.2873.0
Actual_pdf.mov
6.7 MB Download
Expected_pdf.mov
7.4 MB Download

Comment 1 by brajkumar@chromium.org, Oct 10 2016

Labels: -hasbisect hasbisect-per-revision
Owner: rdevlin....@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build:55.0.2872.0(Revision: 420859).
Bad build: 55.0.2873.0 (Revision:421052).

You are probably looking for a change made after 419061 (known good), but no later than 419062 (first known bad).

CHANGELOG URL:
-----------------   https://chromium.googlesource.com/chromium/src/+log/3e7e81ce4bfe1e31d31d9edb5b15472a98b189b9..235441341064c329b155b09235d1aa8e5ea006f4

From the CL above, assigning the issue to the concern owner 

@rdevlin.cronin - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url:  https://codereview.chromium.org/2355183002

Thanks!

Comment 2 by rdevlin....@chromium.org, Oct 10 2016

Cc: rob@robwu.nl
Hey Rob, looks like revision 235441341064c329b155b09235d1aa8e5ea006f4 may have broken some behavior in your pdf extension.  That CL makes it so that onunload listeners don't run for extension pages when the extension is reloaded (see  bug 531378  for why).  Was this extension relying on that?  Is there an alternative?

It's kind of annoying because in this test case, we're just reloading the extension to enable it incognito, but having a general "change behavior for reload" is dangerous, since sometimes the reload will fail.

Comment 3 by rob@robwu.nl, Oct 10 2016 

The tab should stay alive when an extension reloads. Users don't like to lose their tabs, so I have implemented a workaround for bug 511670.

Ideally that bug would be fixed. An example of a satisfactory solution is to just kill the extension tabs instead of closing them (my extension will revive them on load). Perhaps a manifest setting to specify the desired behavior? Or a non-extension page to navigate to (like runtime.setUnistallURL, but then tab or frame-specific. This would also be useful to other extensions that are basically a viewer/stub for a URL, e.g. The Great Suspender extension.

Comment 4 by thestig@chromium.org, Oct 10 2016

Components: -Internals>Plugins>PDF

Comment 5 by brajkumar@chromium.org, Oct 25 2016

Cc: brajkumar@chromium.org
Gentle Ping! Could any one let us know is there any latest update available for this issue?

Comment 6 by brajkumar@chromium.org, Nov 3 2016 

Still issues is reproducible on Ubuntu 14.014 using chrome latest Beta M55-55.0.2883.35. 

rdevlin.cronin@ Ping! Since this issue is marked as P1 for M55, can we get any latest update on this issue?

Comment 7 by kkaluri@chromium.org, Nov 18 2016 

Just to update the latest behavior of the bug, Issue is still observed on chrome latest Dev M55-55.0.2883.52 on windows 10.

rdevlin.cronin@ Could you please let us know is there any recent update available on this issue?

Thanks!

Comment 8 by kkaluri@chromium.org, Nov 25 2016 

Just to update the latest behavior of the bug, Issue is still observed on chrome latest Canary M57-57.0.2931.0

rdevlin.cronin@@ Could you please let us know is there any recent update available on this issue?

Thanks!

Comment 9 by ranjitkan@chromium.org, Dec 2 2016

Cc: pbomm...@chromium.org gov...@chromium.org
@rdevlin.cronin: Gentle ping, Issue is labeled with M55 and it is already in stable. Issue is also marked with a P1 Priority. Kindly provide an update on the same.

Thanks.!

Comment 10 by rdevlin....@chromium.org, Dec 2 2016

Labels: -Pri-1 -M-55 Pri-2
The real issue here is probably bug 511670.  This would be fixed by that.
►

Sign in to add a comment