Bug 14964 – "Safari Extensions Detected" Warning needs to be clearer as to where plugins are installed

• Status: NEW
• Component: Tools / Tests

[Dan Wood]

When launching the nightly webkit build when some sort of Safari extensions are in place, there is a warning with the title "Safari Extensions Detected" that indicates that there may be crashes or incorrect behavior.

It would be very helpful to actually  list the extensions, by name or file path, in this alert.  Personally, I have had trouble hunting down these extensions (since they are installed in a variety of places).

I'm not sure if this alert is actually a function of Safari rather than WebKit, but since the text mentions nightly builds, I'm guessing that the text is at least generated by WebKit.

[Dan Wood]

Created attachment 15959 [details]
screenshot of alert

[Mark Rowe (bdash)]

The FAQ at <http://trac.webkit.org/projects/webkit/wiki/FAQ> lists the paths that contain extensions.  I'm not really sure how the dialog could be clearer without being made more confusing.  Suggestions are welcome.

[Dan Wood]

Perhaps if the following text were added:

For more information, please see the FAQ at http://trac.webkit.org/projects/webkit/wiki/FAQ



(Perhaps a smaller URL could be made to redirect there, since the user will have to type in that URL by hand)

[Brad]

"Suggestions are welcome."

OK, please have a scrolling list of the possible offenders, and then open up their containing folder when you double click on them. I keep getting that message even though I am fairly certain I have removed all of my Safari extensions.

[Mark Rowe (bdash)]

That would require adding custom UI which is not at all desirable given the sensitive time that the dialog is displayed.  As mentioned in comment #2, http://trac.webkit.org/projects/webkit/wiki/FAQ lists the paths that are flagged as extension-carrying.  Any bundles detected in the process from those paths will trigger the dialog after a crash.

[Brad]

Any bundles at all? Not just "Safari Extensions" (those extensions designed specifically to extend Safari)? I don't have any of what I would call Safari Extensions, but perhaps it is triggered by "Smart Crash Reports" or "Detour.ape"?

[Mark Rowe (bdash)]

Yes, any code loaded from those locations.  Arbitrary code running inside Safari can do arbitrary things.  When running a development build of software that the extension developer is unlikely to have tested, the most common thing that arbitrary third-party code running inside Safari will do is crash.

[Brad]

Ah. Then I suggest you don't call them "Safari Extensions" in the alert box then. It is misleading. That is my new suggestion, since you didn't like the other one.

[Mark Rowe (bdash)]

Third-party code that is in Safari's address space is by definition extending Safari.

[Stephen]

(In reply to comment #9)
> Third-party code that is in Safari's address space is by definition extending
> Safari.
> 

You seem set on replying in technical ways, not in ways that assist users in understanding what's actually going on in their computers using Webkit.  Whether something is technically "extending Safari" is not the issue to me. The issue is how Webkit can be happily and efficiently used by a non-technical user such as myself and apparently the other people who posted here.   

[Harold]

OK, I went to all the 'library' files you indicated. Turned off the extensions. STILL GET THE SAME WARNING!
What next?

[Mark Rowe (bdash)]

Open Console.app and look for the "Extension detected" messages.

[Eric Welch]

How about letting us determine which extension does not crash Webkit and selecting it to not be turned off next time Webkit decides it doesn't like its presence, even though it's working perfectly? Mine (I only have one add-on) is 1Password. It works just fine with Webkit, except for when a new build is installed. It inevitably locks up until it crashes, and then I reinstall the plug-in and it works fine until a new build objects to its presence and locks up.

[Mark Rowe (bdash)]

(In reply to comment #13)
> How about letting us determine which extension does not crash Webkit and
> selecting it to not be turned off next time Webkit decides it doesn't like its
> presence, even though it's working perfectly? Mine (I only have one add-on) is
> 1Password. It works just fine with Webkit, except for when a new build is
> installed. It inevitably locks up until it crashes, and then I reinstall the
> plug-in and it works fine until a new build objects to its presence and locks
> up.

WebKit doesn't turn off any extensions.  It merely raises them as a potential problem point if Safari crashes rather than exiting cleanly.