Bug 30151

Summary: Halted plug-ins should restart when hovered
Product: WebKit Reporter: Jon Honeycutt <jhoneycutt>
Component: Plug-insAssignee: Jon Honeycutt <jhoneycutt>
Status: RESOLVED FIXED    
Severity: Normal CC: aroben, eric, hyatt, mitz, simon.fraser
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
Attachments:
Description Flags
patch
none
Expose whether an element is a halted plug-in in HitTestResult
darin: review+, jhoneycutt: commit-queue-
Add SPI to determine whether a node is a halted plug-in
darin: review+, jhoneycutt: commit-queue-
Add SPI to restart a halted plug-in jhoneycutt: commit-queue-

Jon Honeycutt
Reported 2009-10-06 22:20:24 PDT
Plug-ins that have been automatically halted by the PluginHalter should restart when hovered with the mouse. <rdar://problem/7273354>
Attachments
patch (20.26 KB, patch)
2009-10-06 23:51 PDT, Jon Honeycutt 		no flags
DetailsFormatted DiffDiff
Expose whether an element is a halted plug-in in HitTestResult (31.51 KB, patch)
2009-10-14 00:12 PDT, Jon Honeycutt 		darin: review+
jhoneycutt: commit-queue-
DetailsFormatted DiffDiff
Add SPI to determine whether a node is a halted plug-in (7.92 KB, patch)
2009-10-14 22:44 PDT, Jon Honeycutt 		darin: review+
jhoneycutt: commit-queue-
DetailsFormatted DiffDiff
Add SPI to restart a halted plug-in (4.09 KB, patch)
2009-10-15 17:15 PDT, Jon Honeycutt 		jhoneycutt: commit-queue-
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Jon Honeycutt
Comment 1 2009-10-06 23:51:09 PDT
Created attachment 40766 [details] patch
Adam Roben (:aroben)
Comment 2 2009-10-07 08:22:50 PDT
Comment on attachment 40766 [details] patch Couldn't the UI delegate implement this policy using mouseDidMoveOverElement?
Jon Honeycutt
Comment 3 2009-10-07 19:48:18 PDT
Sure - Dan suggested that we could expose that the element is a halted plug-in in mouseDidMoveOverElement(), then add SPI to WebView to restart the plug-in for a given DOM node. Does that sound like a better approach?
Adam Roben (:aroben)
Comment 4 2009-10-08 06:47:57 PDT
(In reply to comment #3) > Sure - Dan suggested that we could expose that the element is a halted plug-in > in mouseDidMoveOverElement(), then add SPI to WebView to restart the plug-in > for a given DOM node. Does that sound like a better approach? That sounds good to me. Maybe we should get Hyatt's opinion before thrashing further.
Jon Honeycutt
Comment 5 2009-10-14 00:12:59 PDT
Created attachment 41152 [details] Expose whether an element is a halted plug-in in HitTestResult I'm working on the test for this.
Simon Fraser (smfr)
Comment 6 2009-10-14 14:33:55 PDT
I don't like adding isOverHaltedPlugin to HitTestResult. If we did this for every other special kind of thing that the mouse can possibly be over, then HitTestResult would large and unwieldy.
Jon Honeycutt
Comment 7 2009-10-14 22:44:01 PDT
Created attachment 41208 [details] Add SPI to determine whether a node is a halted plug-in Rather than adding information about halted plug-ins to HitTestResult, this adds SPI to WebView to determine whether a node is a halted plug-in. Windows side of this. Working on a test.
Jon Honeycutt
Comment 8 2009-10-15 17:13:39 PDT
Landed in http://trac.webkit.org/changeset/49666.
Jon Honeycutt
Comment 9 2009-10-15 17:15:58 PDT
Created attachment 41252 [details] Add SPI to restart a halted plug-in
Jon Honeycutt
Comment 10 2009-10-16 17:58:24 PDT
(In reply to comment #9) > Created an attachment (id=41252) [details] > Add SPI to restart a halted plug-in Kevin Decker reviewed this. It was landed in http://trac.webkit.org/changeset/49699.
Jon Honeycutt
Comment 11 2009-10-16 17:58:54 PDT
Comment on attachment 41252 [details] Add SPI to restart a halted plug-in Clearing review flag.
Eric Seidel (no email)
Comment 12 2009-10-19 15:20:47 PDT
Should this bug still be open?
Jon Honeycutt
Comment 13 2009-10-19 15:55:12 PDT
Nope, closing.
Note You need to log in before you can comment on or make changes to this bug.