Bisect Info:
===========
Good build : 61.0.3125.0 ,  Revision Range -478135
Bad build  : 61.0.3126.0 ,  Revision Range -478483

After executing the per-revision bisect script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/2885ffdad17d2654772d4a4204f805e337660587..e67d603af3065d26e557eb00f964badd71f7d1a3

From the above CL suspecting the below change
---------------------------
https://chromium.googlesource.com/chromium/src/+/e67d603af3065d26e557eb00f964badd71f7d1a3

lfg@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

So, this happened because after I renamed the PDF plugin, it's not considered fully_trusted anymore, just the PDF extension is considered fully_trusted, so the PDF plugin is now subject to the check in PluginServiceImpl::IsPluginUnstable.

If needed, we can easily add the PDF plugin to the fully trusted list.

I'm not really sure if the PDF plugin should be fully trusted, and would like hear the opinion of bauerb@ (OWNER of plugins_*.json) and thestig@ (OWNER of PDF). Thoughts?

If the plugin was had fully_trusted status before, why don't we just give it that status back? I see it gets SECURITY_STATUS_FULLY_TRUSTED which is used in only one place to indicate the plugin is always allowed. Which is fine for the PDF Viewer since it's as up to date as the browser and its native code lives within the chrome binary.

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

commit e8088c308db8b7638082bedd7f31a117b444ce31
Author: Lucas Furukawa Gadani <lfg@chromium.org>
Date: Fri Aug 18 21:43:08 2017

Add pdf plugin to fully_trusted plugins list.

This is necessary because https://chromium-review.googlesource.com/c/518224
split the PDF extension plugin and the PPAPI PDF plugin.

Bug:  752074 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: I6ca5b4c0804e28577739216172561788854d3d82
Reviewed-on: https://chromium-review.googlesource.com/621512
Commit-Queue: Lucas Gadani <lfg@chromium.org>
Reviewed-by: Will Harris <wfh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495697}
[modify] https://crrev.com/e8088c308db8b7638082bedd7f31a117b444ce31/chrome/browser/resources/plugin_metadata/plugins_chromeos.json
[modify] https://crrev.com/e8088c308db8b7638082bedd7f31a117b444ce31/chrome/browser/resources/plugin_metadata/plugins_linux.json
[modify] https://crrev.com/e8088c308db8b7638082bedd7f31a117b444ce31/chrome/browser/resources/plugin_metadata/plugins_mac.json
[modify] https://crrev.com/e8088c308db8b7638082bedd7f31a117b444ce31/chrome/browser/resources/plugin_metadata/plugins_win.json

Update : 
Retested above issue in latest chrome canary #62.0.3192.0 on Windows(7,8,10), Linux(14.04 LTS)& Mac(10.11.6, 10.12.3, 10.12.5) OS and issue is not reproducible. Issue is fixed now and able to reload PDF file even after terminating 'Chrome PDF Plugin' multiple times.

Kindly review an attached screen cast.

Thank you!

Deleted: Latest_behaviour.mp4 1.5 MB

	Latest_behaviour.mp4 1.5 MB View Download