[webkit-dev] How to display new MIME types?
[I’m not sure this is the right forum.] If I want Safari for Mac to display a new MIME type, how do I do it? I know there used to be an Apple-custom API for this, but it was deprecated for classic Netscape plug-ins long ago. However, those NPAPI plug-ins have been deprecated themselves across platforms for many years. There are the newest Safari extensions, which are versions of Apple’s app-extensions API, but those only do JavaScript modifications and such, and don’t cover new types (I think). Am I completely out of luck now? Can I still try NPAPI? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Filling the features.json files
On Apr 8, 2015, at 6:45 PM, Benjamin Poulain wrote: > > On 4/8/15 12:01 PM, Bem Jones-Bey wrote: >> >> On 4/7/15, 21:09, "Benjamin Poulain" wrote: >>> >>> The only mandatory fields are "name" and "status". >> >> What are the valid values for the “status” field, and what is the criteria >> for a feature to be classified under each value? > > -"enabled-by-default" tells if the feature is in WebKit nightly. > -"status" is free text, it will be shown as it is. > -"shipped" is the list of the first release versions shipping the feature. Add, at least eventually, a “retired” column for the release version that dropped the feature. Maybe include a list of newer features that (at least partially) replace it. (An empty list would mean no replacement, or none yet.) > For the status text, I have not made up any rule yet. I used: > -"Done": fully functional, maybe some minor bugs left. > -"Prototyping": proof of concept kind of work. > -"In Development": anything in between the other two. Even something that > barely work can use this. > > Outside status, you can also add "comment" if you want to clarify something, > want feedback, etc. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebView and User Interface Restore
On Sep 21, 2014, at 7:48 PM, Daryle Walker wrote: > Do WebView instances participate in the Resume feature (with > +restoreWindowWithIdentifier: state: completionHandler:, etc.), or do I have > to manually handle their state (the web-view’s back-forward list and which > item is current) myself? I had to turn Resume back on before trying out. My code to bring back the windows worked, but there was nothing in them. I guess WebKit does not do state save/restore and apps like Safari do it manually. Is there any part of that wrong? Any hints on doing it manually? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebView and User Interface Restore
Do WebView instances participate in the Resume feature (with +restoreWindowWithIdentifier: state: completionHandler:, etc.), or do I have to manually handle their state (the web-view’s back-forward list and which item is current) myself? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] How do I find a WebView's desired size?
This is for implementing the windowWillUseStandardFrame:defaultFrame: method on OS X, which enables the green button to do an optimized zoom. How can I find out what height and width a WebView wants to be if it had infinite screen space? If it negotiates the size instead, assume that the maximum width is X and height is Y (which I would compute within windowWillUseStandardFrame:defaultFrame:). These views have scrollbars within their window, so they must have an internal notion of what size they want to be. This has to work whether or not the WebView is showing either HTML or anything else. Asking a similar question on the Cocoa list, a respondent lamented that web browsers these days just punt on the question and go full screen. I don’t want to do that. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Is there a (JavaScript) to test out WebUIDelegate?
I’m trying out Cocoa with a mini web-browser project. My document class holding a WebView object implements the WebUIDelegate informal protocol. I could test out webView:createWebViewWithRequest: by visiting a page that sends all links to a new window/tab. Twitter is a good example of this. It was a pain finding a page with Javascript-generated messages to the status bar, needed to test webView:setStatusText:. Is there a JavaScript test suite so I can try triggering any of the other WebUIDelegate calls. So far I need: //= - (WebView *)webView:(WebView *)sender createWebViewWithRequest:(NSURLRequest *)request; // click links on Twitter - (void)webViewShow:(WebView *)sender; // need a case that doesn’t call webView:createWebViewWithRequest: first - (void)webView:(WebView *)sender setStatusText:(NSString *)text; // went to a JavaScript demo on status-bar messages - (NSString *)webViewStatusText:(WebView *)sender; - (BOOL)webViewIsStatusBarVisible:(WebView *)sender; - (void)webView:(WebView *)sender setStatusBarVisible:(BOOL)visible; //= I need a way to test the second function since it and the first function are usually called together, but my implementation of the first function automatically calls its own version of the second. So I need a way to call the second function by itself. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
