[Webkit-unassigned] [Bug 36893] New: Over-management of Flash boot-up is problematic

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Mar 31 11:09:58 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=36893

           Summary: Over-management of Flash boot-up is problematic
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Plug-ins
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mosesoak at yahoo.com


More than any other browser Firefox tries to actively manage its plug-in
processes, which can cause problems. For example, we have an audio player
that's not shown at first but can be played headless via JS when the user
clicks an HTML thumbnail. Works great in all other browsers, but FF seems to go
out of its way to be sure the hidden audio player cannot properly boot up or be
interacted with via JS.

Originally we wrote special hiding code that moved it off screen but keep it
visible, which worked at the time but now it seems that you guys have tightened
things up even more (!!) -- so now even the offscreen Flash doesn't work. We're
now digging around looking for new workarounds to these weird restrictions.
(..Make the flash 1px? Write special hiding code in our player and special
javascript to target it, and make the flash visible but transparent? It's a
hassle.)

This same general approach also caused us to lose a ton of time debugging our
video player when we found that it didn't load properly in back tabs. FF seems
to allow it to partially boot and run in the hidden tab while somehow
preventing it from detecting its own stage size (embed width/height). We had to
monkey-patch the player's boot cycle so it enters a delay loop until the stage
width is verified to be > 0. Again this weirdness only happens in FF, in other
browsers the Flash seems to boot up only when the tab is selected -- not be
held in limbo in a crippled state.

Suggestions:

A - Fully, not just partially prevent Flash from running in non-active browser
windows. At least don't block it from receiving standard information like stage
size if it is allowed to run.

B - Do not try do somersaults trying to prevent it from running if it's simply
hidden on the active browser page. There are a lot of totally legit use cases
for hidden Flash, like Uploaders and headless audio players, and there is no
immediate security threat in allowing hidden Flash to run. A lot of times Flash
that's hidden is intended to be shown later, such as our audio player, but JS
communication needs to be active to make it usable. And in most cases hidden
Flash is not a resource hog, it's just there to perform some small task for the
HTML.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list