[RFC] [Plugin] Stop old applets from popping up.

[Andrew Su]

Hello,

Currently when navigating to another page, while the first page is loading applets will cause the applet to popup a new window for display, which is then later closed. This patch tries to prevent this by reordering the order of which plugin handles the messages. It originally takes the first few messages to process, and while there is not enough workers, the messages get scrambled (this was because we wanted to look for priority messages and handle them). 

How this patch works:
-When a message is queued by the Stream Handler, it does a check for which of the 4 queues this message belongs to. (priorityQueue, destroyQueue, handleQueue, otherQueue).
--Once the queue has been determines, it appends it to the end of the queue.
-When the message consumer tries to get a message, it goes through the different queues checking the size of each. --Rearranging the order which the checks are performed, we can change which type of messages should take precedence.
--I have chosen to handle it the following way: Priority, Destroy, Initialization (handle), Other.
---I propose handling Destroy before Initialization because this greatly lowers the possibility of applet windows popping up.
---This led to a few minor changes in another part of the code. (more on this after)
-After a message is successfully retrieved, we proceed to handling it.
-The consumer now looks for a free worker to process the message, if no messages are found it will simply place it back onto the FRONT of the appropriate queue. Otherwise, proceed.
--Reason for this is because we want to handle the message in each queue by seniority. (This sort of keep message order)


The minor checked mentioned above are changes to how the PluginAppletViewer handles the destroy and init.
-As I proposed earlier, destroy being handled before init.
--We add two minor synchronization to where we change the status for an identifier (each identifier represents an applet).
---Within the synchronized code in the initialization, we check if the status has already been set for this identifier.
---If so, that means it has already been initialized (this should never happen), or destroy has been called on it.
---The other synchronized block is when the message is not init. In here we check if the message is Destroy and no status is already assigned.
---If so, we will set it to inactive then proceed. (It will noticed it is already inactive and return)
----This takes care of the initializing of the applet so preventing it from creating the applet after we have already navigated to another page.
--Also added checking for inactive applet after parse to prevent exception for applet timeout. (do we need this anymore? If not I shall remove it in another patch)

I am aware of the situation where...the applet is already in initialization stage, then destroy gets called. However, this patch will close it immediately after it finished starting up.


Questions? Comments? Concerns?

Cheers,
--Andrew


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20101008_fix_old_applet_window_popup.patch
Type: text/x-patch
Size: 7612 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20101008/68ac8a53/20101008_fix_old_applet_window_popup.patch