summaryrefslogtreecommitdiffstats
path: root/content/public/browser/browser_plugin_guest_manager.h
Commit message (Collapse)AuthorAgeFilesLines
* Make Edit>Speech>Speak Selection work for PDFs on Macraymes2015-04-171-0/+5
| | | | | | | | | | | | This makes Speak Selection from the menu work for PDFs on Mac. It also simplifies the code slightly by creating a function which gets the "full page" guest if there is one. BUG=476787 Review URL: https://codereview.chromium.org/1042743002 Cr-Commit-Position: refs/heads/master@{#325584}
* GuestViewManager mapped <owner WebContents, element instance ID> => guest ↵fsamuel2015-02-131-3/+2
| | | | | | | | | | | | | | | | instance ID on attachment. This routed IPCs from a given BrowserPlugin to the appropriate guest. Element instance IDs are unique per process. This mapping is fine in Chrome Apps where the embedder doesn't navigate but not for when the embedder is capable of cross-process navigation. In that case, element instance IDs of two BrowserPlugins in two different embedder processes of the same WebContents have the same key, and would thus route to the same guest. This is an issue because the lifetime of the exiting document overlaps with the lifetime of the entering document. Thus, racy behavior can occur. In particular, when navigating from one PDF to another, IPCs for tear down destined for the exiting BrowserPlugin can occasionally get routed to the entering BrowserPlugin. In bug 436339's case, the first step of tear down is to hide the guest content. That IPC ends up going to the entering guest, and so the new PDF is not displayed on screen. This CL fixes the issue by using <embedder process id, element instance ID> as the key to map to a guest instead of the embedder WebContents as the first component. BUG=436339 Review URL: https://codereview.chromium.org/921473006 Cr-Commit-Position: refs/heads/master@{#316328}
* Cleanup BrowserPluginGuestManagerfsamuel2014-08-281-10/+0
| | | | | | | | | | Remove some unnecessary includes, typedefs, and forward declarations. BUG=none Review URL: https://codereview.chromium.org/490923006 Cr-Commit-Position: refs/heads/master@{#292318}
* BrowserPlugin: Simplify guest accessfsamuel2014-08-271-9/+4
| | | | | | | | | | | | | | | Now that it's impossible for content to create guests and it's impossible for a compromised embedder to access a guest it does not have permission to access from content, BrowserPluginGuestManager::MaybeGetGuestByInstanceIDOrKill seems a bit heavy-handed. This CL simplifies the API a bit. This is also a prerequiste to support accessibility in BrowserPlugin. BUG=226145 Review URL: https://codereview.chromium.org/511643002 Cr-Commit-Position: refs/heads/master@{#292060}
* Remove BrowserPlugin's -internal-attach methodfsamuel@chromium.org2014-08-221-2/+2
| | | | | | | | | | | | | | | This CL exposes a much simpler content/public method: void RenderView::AttachToBrowserPlugin(blink::WebNode&) This removes BrowserPlugin's usage of NPAPI method bindings. This will hopefully help us move towards using OOPIFs. BUG=330264 Review URL: https://codereview.chromium.org/444813002 Cr-Commit-Position: refs/heads/master@{#291261} git-svn-id: svn://svn.chromium.org/chrome/trunk/src@291261 0039d316-1c4b-4281-b951-d872f2087c98
* Remove GuestWebContentsCreatedfsamuel@chromium.org2014-06-231-11/+0
| | | | | | | | | | | | | | | | | | | | | This CL introduces GuestViewInternal.createGuest which replaces GuestViewInternal.allocateInstanceId. This new internal API does the following: 1. Allocates an instance ID. 2. Creates a new guest delegate of the specified and guest WebContents, without navigating the new WebContents. 3. On attachment, the new WebContents is navigated. In this CL, the particular GuestView type decides how to create the WebContents. Thus <webview> can create WebContents with SiteInstances of the form chrome-guest:// whereas <appview> can create guests with the SiteInstances matching the app they are hosting. BrowserPluginGuestDelegate (e.g. WebViewGuest) is now passed in to the constructor of BrowserPluginGuest. Now, we can assume a delegate always exists. I added a DCHECK to the constructor. With this patch, BrowserPluginGuestDelegate outlives BrowserPluginGuest too so we can always assume delegate_ is safe to access. BUG=364141 NOTRY=true Review URL: https://codereview.chromium.org/336283002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@279140 0039d316-1c4b-4281-b951-d872f2087c98
* Move allocate instance id to chrome/.lazyboy@chromium.org2014-06-071-2/+0
| | | | | | | | | BUG=364141 Test=No visible change. Review URL: https://codereview.chromium.org/299753011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@275674 0039d316-1c4b-4281-b951-d872f2087c98
* Rename BrowserPluginGuestManagerDelegate to BrowserPluginGuestManagerfsamuel@chromium.org2014-05-111-0/+65
BUG=364141, 330264 TBR=jamescook@chromium.org, michaelbai@chromium.org Review URL: https://codereview.chromium.org/261363002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269705 0039d316-1c4b-4281-b951-d872f2087c98