summaryrefslogtreecommitdiffstats
path: root/chrome/plugin/plugin_thread.cc
Commit message (Collapse)AuthorAgeFilesLines
* Add Cocoa window interposing for plugin processstuartmorgan@chromium.org2009-12-081-46/+0
| | | | | | | | | | | | | | Adds support for noticing window show/hide done via Cocoa APIs. Also adds interposing on a couple more Carbon calls that I came across while debugging. Refactors to make things a bit less messy: - Moves responsibility for re-activating the browser when the last plugin window closes into the browser, to simplify that logic. - Moves utility method for activating the plugin process into the plugin, rather than the interpose library, so the Cocoa code can use it too. - Add a data-holder and a couple of wrapper methods to reduce code duplication in the window show/hide handling. BUG=28009, 29321 TEST=Plugin-opened windows (Gmail attachments, full-screen Flash, etc.) should work as expected again. Review URL: http://codereview.chromium.org/465111 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34074 0039d316-1c4b-4281-b951-d872f2087c98
* Avoid including gtk & glib headers in message_pump_glib.h, saves 1 sec on ↵mattm@chromium.org2009-12-041-0/+4
| | | | | | | | | | | do-nothing make. TEST=manual browser test, trybots BUG=none Review URL: http://codereview.chromium.org/464031 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33851 0039d316-1c4b-4281-b951-d872f2087c98
* Mac: Simulate the OS-level focus handling that windows and linux pluginsamanda@chromium.org2009-11-201-0/+19
| | | | | | | | | | | | rely on to trigger NPAPI keyboard focus notifications. BUG=26585 TEST=On pages with multiple Flash text entry fields, only one should have a blinking caret at any time. Flash elements that use the ActionScript2 "Key.IsDown()" function should only detect keydowns when they are in a visible tab and focused. Review URL: http://codereview.chromium.org/399090 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32631 0039d316-1c4b-4281-b951-d872f2087c98
* Use GetSwitchValuePath.evan@chromium.org2009-11-161-2/+3
| | | | | | | | | | BUG=24672 TEST=unit_tests Patch by Thiago Farina <thiago.farina@gmail.com>. Review URL: http://codereview.chromium.org/375016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32093 0039d316-1c4b-4281-b951-d872f2087c98
* linux: work around "flash does not register any clicks" bugevan@chromium.org2009-11-111-0/+6
| | | | | | | | | | | | | | | | | | I had a flash of inspiration! Setting GDK_NATIVE_WINDOWS in the environment doesn't work because we don't propagate the setting down into the plugin subprocess. I confirmed that setting it manually fixes it. That is, on this computer I previously had the no-clicks bug and with this change the problem is solved. Note: there are multiple confusing levels to this bug; if nspluginwrapper gets involved I still encounter the problem. But this definitely fixes the problem for me. BUG=20654 Review URL: http://codereview.chromium.org/384059 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31734 0039d316-1c4b-4281-b951-d872f2087c98
* Don't allow the browser to stay above a modal plugin window (Mac)stuartmorgan@chromium.org2009-11-041-4/+8
| | | | | | | | | | | There's a flicker of the modal window being hidden then coming forward again, and the menus still work, so we'll most likely have fake the modality more aggressively at some point. This gets us the basic infrastructure though, and solves the severe usability problem. BUG=20798 TEST=Open a modal plugin window (e.g., Gmail upload). Switch to another app, then back to Chrome; the plugin window should come to the front. Review URL: http://codereview.chromium.org/355021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30965 0039d316-1c4b-4281-b951-d872f2087c98
* Fix several issues around fullscreen Mac plugins:amanda@chromium.org2009-10-011-0/+42
| | | | | | | | | | * Keystrokes are now properly sent to plugins in fullscreen mode * When a plugin creates a fullscreen window, we hide the menu bar and restore it when the window is closed BUG=19534,21020 TEST=Open a page with plugins that can go full screen (example: flash video players). Enter full screen mode and verify that esc, arrow keys, spacebar, etc. work as expected. Verify that the menu bar is hidden when the plugin goes fullscreen and is restored when it exits fullscreen mode. Review URL: http://codereview.chromium.org/257008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27755 0039d316-1c4b-4281-b951-d872f2087c98
* Replace the RenderProcessHost.PID function that returns the OS-generatedbrettw@chromium.org2009-08-311-4/+3
| | | | | | | | | | | | | | | | | | | | process ID with an internally-generated id() function. This allows us the guarantee that the IDs are unique over the entire run of the application. This also cleans up some code associated with managing the PID. The main potentially interesting change is now the PID is set uniquely for every creation of RenderProcessHost. It used to be set cleared if the process went away, and re-set if the process was re-created. The ID generation is in ChildProcesInfo so it is also unique between workers and plugins. I had to change some significant things in resource_dispatcher_host_unittest to take into account this new generation of IDs. BUG=17828 TEST=none Review URL: http://codereview.chromium.org/160203 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24899 0039d316-1c4b-4281-b951-d872f2087c98
* linux: call g_thread_init() at relevant startup pointsevan@chromium.org2009-08-251-0/+1
| | | | | | | | | | | | | | | | | | According to glib docs, we need to do this if it's at all possible for us to hit glib on multiple threads. This may be happening when we grab plugin metadata from the file thread. Rather than explicitly depending on gthread all over the place, just put it in with the GTK dep (since anywhere we're using GTK we ought to init gthread). (Note that this is *not* initializing the GDK locking system.) BUG=18957 Review URL: http://codereview.chromium.org/174264 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24207 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "linux: call g_thread_init() at relevant startup points"evan@chromium.org2009-08-251-1/+0
| | | | | | This reverts commit r24203, Mac breakage. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24204 0039d316-1c4b-4281-b951-d872f2087c98
* linux: call g_thread_init() at relevant startup pointsevan@chromium.org2009-08-251-0/+1
| | | | | | | | | | | | | | | | | | According to glib docs, we need to do this if it's at all possible for us to hit glib on multiple threads. This may be happening when we grab plugin metadata from the file thread. Rather than explicitly depending on gthread all over the place, just put it in with the GTK dep (since anywhere we're using GTK we ought to init gthread). (Note that this is *not* initializing the GDK locking system.) BUG=18957 Review URL: http://codereview.chromium.org/174264 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24203 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "linux: call g_thread_init() at relevant startup points"tony@chromium.org2009-08-241-1/+0
| | | | | | | | | | | This reverts commit r24148 because the FDRemapping unittest is failing. TBR=evanm Review URL: http://codereview.chromium.org/173309 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24168 0039d316-1c4b-4281-b951-d872f2087c98
* linux: call g_thread_init() at relevant startup pointsevan@chromium.org2009-08-241-0/+1
| | | | | | | | | | | | | | | | | | According to glib docs, we need to do this if it's at all possible for us to hit glib on multiple threads. This may be happening when we grab plugin metadata from the file thread. Rather than explicitly depending on gthread all over the place, just put it in with the GTK dep (since anywhere we're using GTK we ought to init gthread). (Note that this is *not* initializing the GDK locking system.) BUG=18957 Review URL: http://codereview.chromium.org/174264 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24148 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r24043, "linux: call g_thread_init() at relevant startup points"evan@chromium.org2009-08-211-1/+0
| | | | | | Build failures. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24044 0039d316-1c4b-4281-b951-d872f2087c98
* linux: call g_thread_init() at relevant startup pointsevan@chromium.org2009-08-211-0/+1
| | | | | | | | | | | | | | According to glib docs, we need to do this if it's at all possible for us to hit glib on multiple threads. This may be happening when we grab plugin metadata from the file thread. (Note that this is *not* initializing the GDK locking system.) BUG=18957 Review URL: http://codereview.chromium.org/174264 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24043 0039d316-1c4b-4281-b951-d872f2087c98
* Unrevert 21355 because the revert might be causing thensylvain@chromium.org2009-07-231-41/+15
| | | | | | | | worker tests failures. Review URL: http://codereview.chromium.org/159276 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21412 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 21355 because it might be causing all the newnsylvain@chromium.org2009-07-231-15/+41
| | | | | | | | | | | | crashes on reliability. It also seems to be causing valgrind error. Original change: Switch the first thread in a child process to be the main thread, and make theIO thread be the second thread. The change is needed for plugins on mac. Review URL: http://codereview.chromium.org/159274 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21398 0039d316-1c4b-4281-b951-d872f2087c98
* Switch the first thread in a child process to be the main thread, and make ↵jam@chromium.org2009-07-231-41/+15
| | | | | | | | theIO thread be the second thread. The change is needed for plugins on mac. Review URL: http://codereview.chromium.org/155944 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21355 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the NOTIMPLEMENTED from IsDefaultPluginEnabled for Macstuartmorgan@google.com2009-07-231-1/+1
| | | | | | | | | BUG=17392 TEST=Less console spew on test bots. Review URL: http://codereview.chromium.org/155881 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21351 0039d316-1c4b-4281-b951-d872f2087c98
* Revert r21117 as it caused reliability failures.estade@chromium.org2009-07-211-15/+41
| | | | | | | | | | Also included in this revert: r21165, r21180, and a couple valgrind suppression edits TBR=huanr Review URL: http://codereview.chromium.org/155876 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21216 0039d316-1c4b-4281-b951-d872f2087c98
* Switch the first thread in a child process to be the main thread, and make ↵jam@chromium.org2009-07-201-41/+15
| | | | | | | | the IO thread be the second thread. The change is needed for plugins on mac. Review URL: http://codereview.chromium.org/149558 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21117 0039d316-1c4b-4281-b951-d872f2087c98
* linux: move gtk_init to the right threadpiman@google.com2009-07-101-0/+21
| | | | | | | | | In the plugin process, gtk_init needs to be called from the UI thread (PluginThread) not the main thread (PluginMain) which is an IO thread. Review URL: http://codereview.chromium.org/149424 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20340 0039d316-1c4b-4281-b951-d872f2087c98
* mac/linux: rework plugin channel file descriptor creationevan@chromium.org2009-06-271-11/+10
| | | | | | | | | | | | This CL fixes a bug where the same renderer could open several channels to the same plugin process, which end up having the same name. This CL makes it that there is only one channel for each (plugin, renderer) pair, just like on Windows. The socketpair is created in the plugin process (which can ensure that only one channel per renderer gets created), and sends the renderer side through the browser process. Note: this should essentially be a noop on Windows. Review URL: http://codereview.chromium.org/149062 Patch from Antoine Labour <piman@google.com>. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19448 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-221-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | [re-retry, seeing if reliability bots like it] * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18950 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "posix: two related changes to make plugin IPC work on POSIX."evan@chromium.org2009-06-221-11/+2
| | | | | | | | This looks like it might be to blame for reliability test failures, so I'm trying it out. This reverts commit r18888. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18905 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-201-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | [retry, fix windows compile failure] * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18888 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "posix: two related changes to make plugin IPC work on POSIX."evan@chromium.org2009-06-191-11/+2
| | | | | | This reverts commit r18850, as it had a compile failure. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18851 0039d316-1c4b-4281-b951-d872f2087c98
* posix: two related changes to make plugin IPC work on POSIX.evan@chromium.org2009-06-191-2/+11
| | | | | | | | | | | | | | | | | | | | | | * use a new ChannelHandle type when passing IPC channels over IPC The current POSIX code assumes that one end of a channel is always a new child process (a renderer). For plugins we need to be able to construct channels between each of the browser, plugin, and renderer. This change augments the messages related to creating channels to allow passing in a base::FileDescriptor containing the socket. The intent is that the browser process, as the initial interchange between plugin and renderer, creates the socketpair() on their behalf and hands each their respective end of the connection. * register channel endpoint names in the global pipe map The plugin code assumes it can map from a string to a channel endpoint at basically any time. So whenever we get a channel endpoint over IPC, we install it in a global map of channel endpoints. Review URL: http://codereview.chromium.org/113157 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18850 0039d316-1c4b-4281-b951-d872f2087c98
* Switch child threads so that current() only works on the correct thread and ↵jam@chromium.org2009-06-151-2/+7
| | | | | | | | the correct process. Review URL: http://codereview.chromium.org/126086 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18409 0039d316-1c4b-4281-b951-d872f2087c98
* Fix regression from r11509 which caused each plugin instance to have its own ↵jam@chromium.org2009-06-051-2/+2
| | | | | | | | | | IPC channel (doh!). BUG=119052 TEST=covered by ui test that Amit added Review URL: http://codereview.chromium.org/119158 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17712 0039d316-1c4b-4281-b951-d872f2087c98
* ipc: use strings, not wstrings for channel ids.evan@chromium.org2009-06-041-1/+1
| | | | | | | | | | They're ASCII anyway. TEST=covered by existing tests Review URL: http://codereview.chromium.org/119131 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17682 0039d316-1c4b-4281-b951-d872f2087c98
* linux: we actually already had a bug on file for this NOTIMPLEMENTED.evan@chromium.org2009-05-141-1/+4
| | | | | | Review URL: http://codereview.chromium.org/115367 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16082 0039d316-1c4b-4281-b951-d872f2087c98
* linux (and some posix): multiprocess plugins compiling.evan@chromium.org2009-04-231-4/+20
| | | | | | | | | | | | | | | | | | | The goal of this change is to *not* make any behavioral change, but to instead just get all the plugin-related files linking on Linux with a bunch of NOTIMPLEMENTED()s in the appropriate places. It's enormous enough already without any refactorings or new features. Changes include: - Lots of gcc warning fixes. - Use portable replacements for Windows-specific functions (_strdup, etc.). - Use TransportDIB instead of just shared memory in the plugin messaging. Note that this is not fleshed out on Linux and on Windows it just hacks in the existing handles so there should be no functional change. - Fix --plugin-launcher to use cross-platform APIs. Review URL: http://codereview.chromium.org/79020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14338 0039d316-1c4b-4281-b951-d872f2087c98
* plugins: move NativeLibrary into base.evan@chromium.org2009-04-211-1/+1
| | | | | | | | | | NativeLibrary is used by some plugin code under chrome/. Rather than including webkit/glue there, this relocation is the smallest logical bite to take. :\ Review URL: http://codereview.chromium.org/87012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14071 0039d316-1c4b-4281-b951-d872f2087c98
* Port plugin messages.jam@chromium.org2009-04-011-0/+2
| | | | | | Review URL: http://codereview.chromium.org/49050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12928 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor plugin process code which checks with the browser process before ↵jam@chromium.org2009-03-271-14/+3
| | | | | | | | | | | shutdown, to avoid races in which the browser process thinks the process is fine to use while it's shutting down. I also removed PluginProcess/WorkerProcess since they didn't have any code in them now. I removed the plugin process code which waits 10 seconds before shutting itself down. That was a premature optimization, since testing with/without this didn't show any difference (see http://www/~jabdelmalek/chrome/test/plugins/processes.html). In both cases, the plugin on a page would get recreated in less than 100ms, even with reusing or starting a plugin process from scratch. We already spawn new renderer processes on back and forth if it's a different origin, and the plugin will be in the cache anyways. Review URL: http://codereview.chromium.org/53091 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12703 0039d316-1c4b-4281-b951-d872f2087c98
* Expose whether we're in private browsing mode to plugins.I chose to ↵jam@chromium.org2009-03-261-2/+4
| | | | | | | | | implement this for multi-process mode only and not --single-process or --in-process-plugins, since I wanted to send this data from the browser process, not the renderer (in case it's exploited). BUG=158 Review URL: http://codereview.chromium.org/52037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12588 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a plugin crash due to ResourceDispatcher being used after it was deletedmpcomplete@google.com2009-03-231-1/+5
| | | | | | | | | in PluginThread::CleanUp. BUG=8980 Review URL: http://codereview.chromium.org/50075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12307 0039d316-1c4b-4281-b951-d872f2087c98
* Switch to using one ResourceDispatcher per render process, and move it to ↵jam@chromium.org2009-03-121-6/+0
| | | | | | | | ChildThread so that the same code is used by the plugin process (and soon, workers). Review URL: http://codereview.chromium.org/42108 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11581 0039d316-1c4b-4281-b951-d872f2087c98
* Stop having renderers use both pids and a monotonically increasing ↵jam@chromium.org2009-03-121-3/+3
| | | | | | | | "host_id". This allows ResourceDispatcher to be used by child processes other than renderers. I've done minor related cleanup on the way to make the code simpler. Review URL: http://codereview.chromium.org/42054 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11509 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes CRLF and trailing white spaces.maruel@chromium.org2009-03-051-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10982 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-211-94/+52
| | | | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=10080 Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10144 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 10080.jam@chromium.org2009-02-201-52/+94
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10082 0039d316-1c4b-4281-b951-d872f2087c98
* Refactor code from RenderThread and PluginThread and move it to ChildThread. ↵jam@chromium.org2009-02-201-94/+52
| | | | | | | | | ChildProcess now owns the ChildThread, which removes duplicate code and simplifies things. Clean up ChildProcess, there really was no need for all the templates and statics in it and its subclasses. Review URL: http://codereview.chromium.org/21502 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10080 0039d316-1c4b-4281-b951-d872f2087c98
* Move proxy resolve requests out of plugin/renderer process, and into the ↵ericroman@google.com2009-01-311-0/+32
| | | | | | | | browser. Review URL: http://codereview.chromium.org/14142 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9006 0039d316-1c4b-4281-b951-d872f2087c98
* New implementations of core plugin libraries.avi@google.com2009-01-151-1/+1
| | | | | | Review URL: http://codereview.chromium.org/17427 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8122 0039d316-1c4b-4281-b951-d872f2087c98
* Change "dll" to "plugin" where appropriate.avi@google.com2009-01-061-1/+1
| | | | | | Review URL: http://codereview.chromium.org/16543 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7617 0039d316-1c4b-4281-b951-d872f2087c98
* Move plugins to FilePaths, some cleanupavi@google.com2009-01-061-1/+1
| | | | | | Review URL: http://codereview.chromium.org/16456 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7588 0039d316-1c4b-4281-b951-d872f2087c98
* This is a patch for bug 1385045: Adobe Acrobat 9.0 crash.nsylvain@chromium.org2008-10-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adobe Acrobat 9.0 loads a dll called bib.dll. Usually it unloads it 30 seconds after the last instance of the plugin goes away, or when the browser process goes away. To know if the browser process goes away, it subclasses the main browser window. It seems to work fine in firefox, but it does not work in chrome. Also the 30 seconds delay does not work because we close the plugin process too fast (10 seconds) after the last instance of the plugin is closed. bib.dll is then unloaded by ExitProcess, which causes a crash in bib.dll. We could wait ~35 seconds after the last instance before closing the process, but it might be problematic with upgrades and could result in plugin process outliving the brower process. This current patch just kills the process before ExitProcess, so it does not cause a crash and display an error message to the user. This is not a fix, this is just a usuability improvement. As far as I know we are still waiting for help from the Adobe team on this issue. They would need to find a way to unload bib.dll cleanly in chrome. BUG: 1385045 Review URL: http://codereview.chromium.org/8015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3753 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a crashing bug when shutting down the plugin process.michaeln@google.com2008-09-051-1/+1
| | | | | | Review URL: http://codereview.chromium.org/459 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1747 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-07 21:06:55 +0000