Bug 103206 - Keep track of plug-in snapshots clicked by user
Summary: Keep track of plug-in snapshots clicked by user
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.8
: P2 Normal
Assignee: Jon Lee
URL:
Keywords: InRadar
Depends on: 103655 103664
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-25 15:49 PST by Jon Lee
Modified: 2012-12-10 17:34 PST (History)
19 users (show)

See Also:


Attachments
Patch (62.11 KB, patch)
2012-11-26 15:31 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (63.18 KB, patch)
2012-11-27 02:14 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (63.46 KB, patch)
2012-11-27 10:18 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (63.46 KB, patch)
2012-11-27 12:12 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (52.36 KB, patch)
2012-11-27 15:59 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (63.30 KB, patch)
2012-11-27 16:13 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (63.66 KB, patch)
2012-11-27 20:22 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (33.67 KB, patch)
2012-11-29 14:26 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (78.79 KB, patch)
2012-12-07 01:38 PST, Jon Lee
no flags Details | Formatted Diff | Diff
Patch (51.73 KB, patch)
2012-12-10 15:24 PST, Jon Lee
andersca: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Lee 2012-11-25 15:49:10 PST
Plug-ins that are clicked by the user should start automatically the next time they are loaded.
Comment 1 Jon Lee 2012-11-25 15:50:03 PST
<rdar://problem/12746483>
Comment 2 Jon Lee 2012-11-26 15:31:48 PST
Created attachment 176092 [details]
Patch
Comment 3 EFL EWS Bot 2012-11-26 15:50:41 PST
Comment on attachment 176092 [details]
Patch

Attachment 176092 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/14991730
Comment 4 Jon Lee 2012-11-27 02:14:44 PST
Created attachment 176207 [details]
Patch
Comment 5 Peter Beverloo (cr-android ews) 2012-11-27 03:01:50 PST
Comment on attachment 176207 [details]
Patch

Attachment 176207 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/15016033
Comment 6 WebKit Review Bot 2012-11-27 09:04:07 PST
Comment on attachment 176207 [details]
Patch

Attachment 176207 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/15018100
Comment 7 Jon Lee 2012-11-27 10:18:09 PST
Created attachment 176292 [details]
Patch
Comment 8 Peter Beverloo (cr-android ews) 2012-11-27 11:50:13 PST
Comment on attachment 176292 [details]
Patch

Attachment 176292 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/15015168
Comment 9 Jon Lee 2012-11-27 12:12:09 PST
Created attachment 176318 [details]
Patch
Comment 10 Darin Adler 2012-11-27 12:12:36 PST
Comment on attachment 176292 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176292&action=review

> Source/WebKit/efl/ChangeLog:13
> +        (PlatformStrategiesEfl):

Should remove bogus lines like this from change logs.

> Source/WebKit/gtk/ChangeLog:13
> +        (PlatformStrategiesGtk):

And this.

> Source/WebKit/mac/ChangeLog:10
> +        (WebPlatformStrategies):

And this.

> Source/WebKit/qt/ChangeLog:13
> +        (PlatformStrategiesQt):

And this.

> Source/WebKit/win/ChangeLog:13
> +        (WebPlatformStrategies):

And this.

> Source/WebKit/wince/ChangeLog:13
> +        (PlatformStrategiesWinCE):

And this.

> Source/WebCore/html/HTMLPlugInImageElement.cpp:295
> +    m_plugInOriginHash = plugInOriginHash(document()->page(), url);

This assumes that page is non-null.

> Source/WebCore/html/HTMLPlugInImageElement.cpp:296
> +    if (document()->page()

Then this checks that page is non-null. Too late by now because plugInOriginHash would have crashed.

> Source/WebCore/platform/PlugInOriginHash.cpp:38
> +static ALWAYS_INLINE PlugInOriginHash plugInOriginHashInline(const CharacterType* origin, unsigned length)

Why is ALWAYS_INLINE needed rather than just inline?

> Source/WebCore/platform/PlugInOriginHash.cpp:40
> +    return AlreadyHashed::avoidDeletedValue(StringHasher::computeHash(origin, length));

I think this should be a case folding hash.

This returns a 64-bit type, but I believe StringHasher returns only a 32-bit value.

> Source/WebCore/platform/PlugInOriginHash.cpp:45
> +    const KURL& mainFrameBaseURL = page->mainFrame()->document()->baseURL();

This local variable is not needed. The code reads more clearly without it.

> Source/WebCore/platform/PlugInOriginHash.cpp:50
> +    StringBuilder builder;
> +    builder.append(mainFrameBaseURL.host());
> +    builder.append(srcURL.host());
> +
> +    String hashString = builder.toString();

Building a concatenated string is not an efficient way to hash the two strings because of the additional memory allocation needed. There are alternate approaches that don’t require memory allocation or that don’t require copying all the characters. It’s a little strange to go to the trouble of making an optimized 8-bit code path when the performance cost of building the string in the first place is pretty high.

Normally we’d include a separator between the two strings to get hashed in the right way.

> Source/WebCore/platform/PlugInOriginHash.cpp:51
> +    ASSERT(hashString.length());

What guarantees the URLs have non-empty host strings? What if they are both file URLs?

> Source/WebKit/qt/WebCoreSupport/PlatformStrategiesQt.cpp:161
> +    // FIXME: Implement.

Is it really right to say we need these implemented on every platform? Not every platform will necessarily want this feature. It’s be nice to not put all these FIXMEs in, since there’s nothing to fix unless someone wants this feature to work.

> Source/WebKit2/Shared/Plugins/PlugInAutoStartTable.h:35
> +typedef HashSet<WebCore::PlugInOriginHash> PlugInAutoStartTable;

I’m not sure it’s worth having a while header file just for a HashSet typedef. We could just repeat the type twice in the two file it’s used in.
Comment 11 Michael Saboff 2012-11-27 13:31:01 PST
Comment on attachment 176318 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176318&action=review

> Source/WebCore/platform/PlugInOriginHash.cpp:54
> +    return plugInOriginHashInline(hashString.characters(), hashString.length());

Use characters16() since we know the string is 16 bits at this point.
Comment 12 Jon Lee 2012-11-27 13:44:09 PST
Comment on attachment 176292 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=176292&action=review

>> Source/WebKit/efl/ChangeLog:13
>> +        (PlatformStrategiesEfl):
> 
> Should remove bogus lines like this from change logs.

I've removed all of these.

>> Source/WebCore/html/HTMLPlugInImageElement.cpp:295
>> +    m_plugInOriginHash = plugInOriginHash(document()->page(), url);
> 
> This assumes that page is non-null.

Added a check for page before this assignment...

>> Source/WebCore/html/HTMLPlugInImageElement.cpp:296
>> +    if (document()->page()
> 
> Then this checks that page is non-null. Too late by now because plugInOriginHash would have crashed.

... and removed this check here.

>> Source/WebCore/platform/PlugInOriginHash.cpp:38
>> +static ALWAYS_INLINE PlugInOriginHash plugInOriginHashInline(const CharacterType* origin, unsigned length)
> 
> Why is ALWAYS_INLINE needed rather than just inline?

I took this from VisitedLinkHash, but after talking with Michael about this realized it was unnecessary. Switched to inline.

>> Source/WebCore/platform/PlugInOriginHash.cpp:40
>> +    return AlreadyHashed::avoidDeletedValue(StringHasher::computeHash(origin, length));
> 
> I think this should be a case folding hash.
> 
> This returns a 64-bit type, but I believe StringHasher returns only a 32-bit value.

Yes. A different scheme will be used (see below).

>> Source/WebCore/platform/PlugInOriginHash.cpp:45
>> +    const KURL& mainFrameBaseURL = page->mainFrame()->document()->baseURL();
> 
> This local variable is not needed. The code reads more clearly without it.

Done.

>> Source/WebCore/platform/PlugInOriginHash.cpp:50
>> +    String hashString = builder.toString();
> 
> Building a concatenated string is not an efficient way to hash the two strings because of the additional memory allocation needed. There are alternate approaches that don’t require memory allocation or that don’t require copying all the characters. It’s a little strange to go to the trouble of making an optimized 8-bit code path when the performance cost of building the string in the first place is pretty high.
> 
> Normally we’d include a separator between the two strings to get hashed in the right way.

We can expand the hash space by instead hashing the two origins separately and then concatenating them into a 64-bit hash. We avoid the allocation that way, also.

>> Source/WebCore/platform/PlugInOriginHash.cpp:51
>> +    ASSERT(hashString.length());
> 
> What guarantees the URLs have non-empty host strings? What if they are both file URLs?

I'll add a check for an empty string, and substitute "localhost" in that case.

>> Source/WebKit/qt/WebCoreSupport/PlatformStrategiesQt.cpp:161
>> +    // FIXME: Implement.
> 
> Is it really right to say we need these implemented on every platform? Not every platform will necessarily want this feature. It’s be nice to not put all these FIXMEs in, since there’s nothing to fix unless someone wants this feature to work.

I've remove them.

>> Source/WebKit2/Shared/Plugins/PlugInAutoStartTable.h:35
>> +typedef HashSet<WebCore::PlugInOriginHash> PlugInAutoStartTable;
> 
> I’m not sure it’s worth having a while header file just for a HashSet typedef. We could just repeat the type twice in the two file it’s used in.

I agree, but this was included in anticipation of switching to a shared memory model instead of a copied model, like the visited link table.
Comment 13 Jon Lee 2012-11-27 15:59:36 PST
Created attachment 176354 [details]
Patch
Comment 14 Early Warning System Bot 2012-11-27 16:11:05 PST
Comment on attachment 176354 [details]
Patch

Attachment 176354 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/15018211
Comment 15 Early Warning System Bot 2012-11-27 16:13:32 PST
Comment on attachment 176354 [details]
Patch

Attachment 176354 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/15000827
Comment 16 Jon Lee 2012-11-27 16:13:57 PST
Created attachment 176360 [details]
Patch
Comment 17 Jon Lee 2012-11-27 20:22:18 PST
Created attachment 176388 [details]
Patch
Comment 18 Jon Lee 2012-11-29 14:26:47 PST
Created attachment 176817 [details]
Patch
Comment 19 Jon Lee 2012-12-07 01:38:18 PST
Created attachment 178185 [details]
Patch
Comment 20 WebKit Review Bot 2012-12-07 01:43:01 PST
Attachment 178185 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1
Source/WebCore/page/Page.h:175:  More than one command on the same line in if  [whitespace/parens] [4]
Source/WebCore/page/Page.h:255:  The parameter name "volume" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 2 in 29 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 21 Jon Lee 2012-12-10 15:24:59 PST
Created attachment 178649 [details]
Patch
Comment 22 Jon Lee 2012-12-10 17:34:10 PST
Committed r137230: <http://trac.webkit.org/changeset/137230>