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

2007-05-25 Thread Rudi Sherry

On May 22, 2007, at 12:02 PM, Nathan Duran wrote:

I need to add a set of menu items to the contextual menu that  
WebKit based
browsers display in response to a control click on standard image  
files
which do not require plugins to view. My first thought was that I  
would be
able to create a dummy plugin which registered itself for all the  
same MIME
types as WebImageView, and then just go ahead and instantiate one  
of those

after poking in a UI delegate to generate the new menu items. snip


Actually, even if WebImageView still existed this method won't work,  
as the images are used without any plug-in interaction.


See http://bugs.webkit.org/show_bug.cgi?id=10015 for more  
background.  The prevailing view is that all mime types are equal ...  
but some are more equal than others.  Quoting a comment in the bug:



 Fundamental image types and fundamental document types should not be
overridable by plugins.  This would allow plugins to take over  
basic image
rendering and even HTML document or XML document rendering.  This  
is roughly
analogous to the way browsers will still display HTML on their own  
even if the

OS thinks another browser is registered as the default.


I'm on record as accepting of, but not agreeing with, this argument ;)

Rudi

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread Nathan Duran
 I'm on record as accepting of, but not agreeing with, this argument ;)

Well it makes at least as much sense as the Contextual Menu Manager API's
continued existence does :)

It strikes me as rather silly to protest giving free reign to plugin
developers in the interest of maintaining some territorial sense of purity
(that QuickTime vs. PNG argument is pretty flimsy) when all it does is force
said developers to craft even dirtier solutions--such as the rampant abuse
of Input Managers. I patched enough traps in my day to know that the
practice of overriding stock behavior is fraught with pitfalls, but it's
always far more preferable to risk destabilizing one specific application
rather than the entire OS whenever possible. Plus the hooks are already
there, dangling in front of your face just out of reach.  


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread David Hyatt


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


(that QuickTime vs. PNG argument is pretty flimsy) when all it does  
is force


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.


Plug-ins should not be allowed to break your browser.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread David Hyatt
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.


dave

On May 25, 2007, at 4:15 PM, David Hyatt wrote:



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


(that QuickTime vs. PNG argument is pretty flimsy) when all it  
does is force


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.


Plug-ins should not be allowed to break your browser.

dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread Maciej Stachowiak


On May 25, 2007, at 4:18 PM, David Hyatt wrote:

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.


Yeah, I don't get how it got there either. If you want to change  
context menus, then in a custom WebKit app, you can use the UI  
delegate: webView:contextMenuItemsForElement:defaultMenuItems:


If you want to do it from web content, I think your only option right  
now is to handle the contextmenu event and pop up a custom menu by  
hand.


In the future, HTML is going to get better support for customizing  
context menus from web content. Here's the current HTML5 draft:  
http://www.whatwg.org/specs/web-apps/current-work/#context. If you  
need a feature like this sooner rather than later, contact the  
appropriate WWDR representative.


Regards,
Maciej





___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread Maciej Stachowiak


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

I'm on record as accepting of, but not agreeing with, this  
argument ;)


Well it makes at least as much sense as the Contextual Menu Manager  
API's

continued existence does :)

It strikes me as rather silly to protest giving free reign to plugin
developers in the interest of maintaining some territorial sense of  
purity
(that QuickTime vs. PNG argument is pretty flimsy) when all it does  
is force
said developers to craft even dirtier solutions--such as the  
rampant abuse

of Input Managers.


It's not just sense of purity - the browser makes assumptions that  
certain types will be handled directly and counts on this to give a  
consistent user experience and for its internal workings. Pretty much  
all browsers reserve their built-in types. Many plugins mistakenly  
claim built-in types, since other browsers ignore that, and content  
would break in Safari if we don't do it right.


Anyway, if you are trying to change context menus from a custom  
WebKit app you don't have to use any hacks, there is an API for it  
(WebUIDelegate).


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread Nathan Duran
 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.

There is absolutely nothing you can possibly do to stop people from
installing stupid things on their computers. The best you can hope to
accomplish is to provide your developers with simple, clearly documented
methods to accomplish their goals in order to reduce the risk of
catastrophic failure.

 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 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.

 Plug-ins should not be allowed to break your browser.

Right, only Apple employees should be allowed to do that.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-25 Thread 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


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

2007-05-22 Thread Nathan Duran
I need to add a set of menu items to the contextual menu that WebKit based
browsers display in response to a control click on standard image files
which do not require plugins to view. My first thought was that I would be
able to create a dummy plugin which registered itself for all the same MIME
types as WebImageView, and then just go ahead and instantiate one of those
after poking in a UI delegate to generate the new menu items. Unfortunately,
I cannot find any sort of public interface or implementation for
WebImageView anywhere in the WebKit source tree (so much for open source),
and as far as I can tell, plugin code never executes unless there's content
for it, so this doesn't seem like it's going to work out.

I'd rather not go the generic Contextual Menu Plugin route, as I don't want
this code running anywhere other than WebKit browsers, and it seems as
though there would be a great deal of hideous coercion involved in getting a
pointer to the WebView the WebKit plugin protocol hands you for free. SIMBL
and Haxies are similarly right out of the picture.

I searched through the archives and the only mention I could find of
anything similar pertained to something known as SafariStand, and the
explanatory link that was offered has long since gone dead. Is there any
officially sanctioned means of accomplishing what seems like it should be a
fairly trivial feat, or am I stuck guessing at what WebImageView does based
on its method names?



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev