[webkit-dev] Augmenting WebKit contextual menus for non-plugin content

[David Hyatt]

On May 25, 2007, at 4:39 PM, Nathan Duran wrote:

>> Flimsy in what sense?  If QuickTime (or any plugin) can take over
>> PNG, then PNG image support when the <object> tag is used would
>> effectively be broken.  Suddenly all sorts of built-in browser
>> functionality breaks.  Web sites would break.  The end user would
>> have no real understanding of what was going wrong or how to fix it.
>
> Flimsy in the sense that QuickTime should have simply stopped  
> registering
> itself to handle that MIME type rather than making it impossible  
> for ANY
> plugin to register itself for any MIME type. That's like trying to  
> keep
> fleas off your dog by draining all the blood out of it.
>

I think there is some confusion here, so I will try to clarify.

<img src="foo.png">
<object src="foo.png">

should not render differently in a browser.  It would be inconsistent  
for a plug-in to render the PNG in the latter case but not in the  
former case.

Right now plug-ins can only be declared via an <object>/<embed>  
element.  There is no other way to make a browser plug-in in HTML.

If we allow plug-ins to take over image types in the <object> case,  
then suddenly there are two conflicting implementations of PNG at  
work depending on what tag the author of the Web page happened to  
use.  See the problem?

Now maybe you are asking for a feature whereby some hunk of code  
could really take over the MIME type regardless of where it occurs in  
the browser (e.g., PNGs can occur as background images in CSS, in the  
<img> URL, drawn to a <canvas> etc.).  If so that goes way beyond the  
concept of a plug-in.  That may be an interesting feature to  
implement, but it would not be a plug-in as defined in browsers today.

>
>> Augmenting contextual menus really has nothing to do with plug-ins,
>> so I'm not sure how the conversation ended up at plug-ins.  :)
>> Changing context menus is getting more into the realm of extensions.
>
> Semantics are fun, aren't they? How about if we invent a third  
> category and
> call them "add-ons" just to delineate some more imaginary  
> boundaries that
> keep those bug reports in someone else's inbox?
>

I'm not playing a semantic game here.  Plug-ins have a precise  
meaning and a precisely defined API (the Netscape plug-in API).  The  
Netscape plug-in API defines how a plug-in interacts with the Web  
page in a formal cross-browser way.

I'm just distinguishing the defined notion of plug-in in browsers  
from something new (that would be better classified as a browser  
extension using Firefox terminology).
> I get the fact that it doesn't work the way I want it to and  
> probably never
> will. That doesn't mean that this is an ideal situation which I  
> have no
> right to find objectionable.
>

Nobody said the ability to customize context menus was an  
objectionable feature.

dave