| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
load when the plugin calls NPN_RequestRead. I was looking at the wrong
stream implementation in Firefox :(
Bug=5009
TBR=jam
Review URL: http://codereview.chromium.org/13212
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6454 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NPN_RequestRead to initiate seekable byte range requests on the stream. While the contract on the plugins part is not fully clear from the mozilla docs, this is what Firefox does.
This also improves performance greatly as the manual data stream already has most of the data which the plugin requests anyway. I verified this with large PDF files around 14-15MB. We are twice as faster with this fix.
This fixes http://code.google.com/p/chromium/issues/detail?id=5009, which is an issue with the PDF file not loading at times. The problem also occurs at times in Firefox when we set breakpoints and thus slow down the operation.
The Reader plugin displays its UI in child windows on a separate thread in the plugin process. These are parented to the plugin window which lives on the plugin thread. The plugin thread unfortunately is treated as an IO thread by
the plugin and it uses the SendMessage API to send messages to the plugin thread and back. If the plugin fails to receive data for the PDF file in a reasonable time,
it just destroys the PDF window hierarchy causing this issue.
Handing the data off the manual data stream along with the byte range data speeds up the whole operation and thus avoids this issue to a great extent.
Bug=5009
R=jam
Review URL: http://codereview.chromium.org/12960
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6396 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes http://code.google.com/p/chromium/issues/detail?id=3977, which is an issue with Acrobat Reader internet preferences being set to always open PDF files in Reader. This operation when performed in chrome and Safari
brings up an error message from the Acrobat Reader plugin that the file could not be found.
The plugin in this case returns NP_ASFILE as the plugin mode from NPP_NewStream. The data is written accordingly to the temp file created. When we finish receiving the data we pass the file name in NPP_StreamAsFile to the plugin. The plugin does not open the file immediately as per our expectation. It opens the file after the stream has been destroyed which ends up deleting the temp file created above.
Debugged Firefox and found that it never deletes these temp files and leaves them around in the cache.
We can go one step forward and track all these files on a per instance basis. These are deleted when the plugin instance is destroyed.
Bug=3977
R=jam
Review URL: http://codereview.chromium.org/12875
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6245 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
| |
an issue with videos on sites like thedailyshow.com not showing up in Chrome. We recently made a change to send out the plugin SRC as the referrer in requests initiated by plugins.We also use the GetURLNotify codepath for requests which are initiated by us when the plugin is instantiated. It looks like the other browsers don't do the same, and only use the SRC as the referer for explicit plugin requests.Based on a reply on the PluginFutures list we emulate this behavior, which is to default to the containing frame URL as the referer for requests not initiated by plugins.
R=jam
Review URL: http://codereview.chromium.org/7871
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3862 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
| |
- ifdef out windows specific calls
- fix simple compiler warnings
Review URL: http://codereview.chromium.org/7886
Patch from icefox.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3794 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the alpha channel sometimes.
This change introduces another buffer which holds the background image for transparent plugins. Before
painting these plugins, their backing store is overwritten with the background data.
This change also uses an ACK from the renderer to figure out when it can paint, similar to how the
renderer does it, which gives us throttling and also doesn't lead to painting when the tab is hidden.
Review URL: http://codereview.chromium.org/5040
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2744 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
| |
http://code.google.com/p/chromium/issues/detail?id=206This is a performance issue while loading PDF documents. The fix is to support PDF fast webview, which is basically support for the NPN_RequestRead API, which allows a plugin to request specific byte ranges in HTTP GET requests. This also needs support for seekable streams. Our support for seekable streams is limited to HTTP servers which allow byte range requests. Firefox also supports a mode in which the the browser caches the file on disk for servers which don't support byte range requests. The plugin_data_stream.cc/.h files are being removed as there is not much value in their existence. The needed functionality is available in the PluginStreamUrl class, which now services manual data streams as well. Testing this is a touch tricky as we need a HTTP server which serves byte range requests. Will add those in a subsequent CB.Also fixed a bug in the multipart parser where we need to ignore leading newline characters while parsing the header.Bug=206
Review URL: http://codereview.chromium.org/2896
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2400 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
was a crash in the 3dvia plugin. A script on the page tries to interact
with the plugin by obtain its npobject. The plugin's does not implement the
corresponding NPP_GetValue function correctly and returns NPERR_NO_ERROR
without filling in the NPObject pointer passed in.
The fix is to initialize the NPObject pointer on the stack to NULL and check
for this along with the error check.
Review URL: http://codereview.chromium.org/212
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1692 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1122 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1118 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
| |
uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1113 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18 0039d316-1c4b-4281-b951-d872f2087c98
|
