Bug 134528

Summary:

Improve handling of primary offscreen plugins

Product:

WebKit

Reporter:

Roger Fong <roger_fong>

Component:

Plug-ins

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bunhere, cdumez, clopez, commit-queue, dino, gyuyoung.kim, jonlee, roger_fong, sergio, thorton

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
patch	none

Description Roger Fong 2014-07-01 17:12:32 PDT

I noticed two issues with the handling of the primary off screen plugin case.
The first is that the determination of whether or not the plugin started off screen was happening too late, not at the initialization of the plugin as it should have been.
The second issue is that the plugin process type was being set to PluginProcessTypeSnapshot for these potential offscreen plugins. 
This caused them to be muted. The process type should instead be switched to PluginProcessTypeNormal. 
Note that setting the display state of the plugin to DisplaySnapshot also causes the plugin to be muted.
Alternatively, in the case where we do want to display a snapshot I could also recreate and reinitialize the plugin and force the plugin process type to be PluginProcessTypeSnapshot.

<rdar://problem/17471864>

Comment 1 Roger Fong 2014-07-01 17:16:47 PDT

Created attachment 234223 [details]
patch

Comment 2 Roger Fong 2014-07-02 00:06:28 PDT

This is a followup to https://bugs.webkit.org/show_bug.cgi?id=133667

Comment 3 Dean Jackson 2014-07-02 17:45:18 PDT

Comment on attachment 234223 [details]
patch

Can we test this?

PS. GTK failed. Didn't look :)

Comment 4 Roger Fong 2014-07-02 19:59:14 PDT

(In reply to comment #3)
> (From update of attachment 234223 [details])
> Can we test this?
Hmmm I suppose i can write a test which pulls in a fairly largely sized plugin from offscreen and have it play audio.
So I'd need a regular layout test result and an audio result...do audio results even work these days?

> 
> PS. GTK failed. Didn't look :)
Meh, unrelated failures.

Comment 5 WebKit Commit Bot 2014-07-02 20:31:27 PDT

Comment on attachment 234223 [details]
patch

Clearing flags on attachment: 234223

Committed r170743: <http://trac.webkit.org/changeset/170743>

Comment 6 WebKit Commit Bot 2014-07-02 20:31:31 PDT

All reviewed patches have been landed.  Closing bug.

Comment 7 Carlos Alberto Lopez Perez 2014-07-02 20:41:43 PDT

(In reply to comment #4)
> > PS. GTK failed. Didn't look :)
> Meh, unrelated failures.

unrelated failures??? This just broke the GTK build: http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/48974/steps/compile-webkit/logs/stdio

Comment 8 Carlos Alberto Lopez Perez 2014-07-02 21:11:05 PDT

(In reply to comment #7)
> (In reply to comment #4)
> > > PS. GTK failed. Didn't look :)
> > Meh, unrelated failures.
> 
> unrelated failures??? This just broke the GTK build: http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/48974/steps/compile-webkit/logs/stdio

It also broke the EFL build. 

Reported here: https://bugs.webkit.org/show_bug.cgi?id=134585

Comment 9 Roger Fong 2014-07-02 21:35:04 PDT

(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #4)
> > > > PS. GTK failed. Didn't look :)
> > > Meh, unrelated failures.
> > 
> > unrelated failures??? This just broke the GTK build: http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/48974/steps/compile-webkit/logs/stdio
> 
> It also broke the EFL build. 
> 
> Reported here: https://bugs.webkit.org/show_bug.cgi?id=134585

Sorry bout that, I was looking at what I thought was GTK test results which would've implied GTK built successfully.