On Fri, May 22, 2015 at 1:25 AM, Anders Carlsson wrote:
> Sam Weinig 2015-05-15 10:12:54 PDT:
>> Support for navigator.registerProtocolHandler/unregisterProtocolHandler is
>> not something we want to support in WebKit2 at this time as we are not
>> confident it is a good Web API. This might be a
On Fri, May 22, 2015 at 12:26 PM, Maciej Stachowiak wrote:
> (I am more dubious of the content handler aspect.)
Agreed, especially as it requires the service to download the resource
again. For that use case we need something smarter where you can pass
along an object/stream of sorts I think.
-
On Fri, May 22, 2015 at 1:50 PM, Gyuyoung Kim wrote:
> I also don't want to support the "content handler" feature at the moment.
> The feature might be more clear and mature. The patch of Bug 92749 only
> supports registerProtocolHandler,
> and unregisterProtocolHandler and isProtocolHandlerRegist
On Fri, May 22, 2015 at 6:43 PM, Gyuyoung Kim wrote:
> Current implementation doesn't hook to HTML's navigation directly. We
> delegate the html navigation(or call native application) to application.
> Application is able to decide to navigate the given html page or execute
> native application th
Hi,
The WHATWG is considering removing mediagroup/MediaController from
HTML, since other than WebKit no browser project has expressed
interest in this feature.
https://github.com/whatwg/html/issues/192 is the corresponding issue.
I would recommend following up in the issue itself if this is
prob
On Wed, Mar 22, 2017 at 3:55 PM, Alexandre GOUAILLARD
wrote:
> that s great to have now chrome AND webkit doing it. I hope mozilla and the
> other will follow, as discussed on the side of BlinkOn last year.
FWIW, Mozilla already periodically synchronizes with WPT. Think we
were first even.
--
On Tue, May 9, 2017 at 8:27 PM, Simon Fraser wrote:
> I'm also concerned that with 4 vendors upstreaming their WPT tests, the WPT
> repo will just become a morass of partially overlapping tests that takes 4x
> longer to run than a curated repo.
Why do you think WPT is not curated? It's an activel
On Fri, May 12, 2017 at 6:46 AM, Simon Fraser wrote:
> I was under the impression that tests upstreamed from vendor repositories
> would land in WPT tests
> with minimal review, based on the fact that they had been reviewed when
> landed in the vendor repo.
I think that's under the expectation
On Fri, May 12, 2017 at 11:49 PM, Maciej Stachowiak wrote:
> It seems like there's two unusual things about WPT:
> - At least according to Alexey, WPT tests are somewhat prone to flakiness in
> Safari.
Although they haven't always been working perfectly, changes to
web-platform-tests run through
On Sun, May 14, 2017 at 8:24 AM, Maciej Stachowiak wrote:
> For the engineer use case, we can make a command-line tool to launch the
> server and load the test. But it's kind of sad that in ~95% of cases, the
> only value provided by the server is resolving the path to testharness.js. If
> test
On Tue, May 16, 2017 at 5:45 AM, Ryosuke Niwa wrote:
>> I think the main problem with not running a server is that behavior
>> for file URLs is not defined. And browsers tend to impose different
>> restrictions there. So you might end up debugging something only to
>> later found out it didn't wor
On Tue, May 16, 2017 at 7:29 AM, Ryosuke Niwa wrote:
> Given we're talking about how these tests are ran inside WebKit,
> whether there is an agreement about this or not is sort of irrelevant.
> If a test doesn't run as expected, we can run it inside a HTTP server.
I was just trying to help clari
On Fri, May 19, 2017 at 5:11 PM, youenn fablet wrote:
> When a spec gets updated, the WPT tests will ideally be updated at the same
> time.
> The updated tests will no longer ensure non-regression until the browser
> implements the new behavior.
Ideally if importing test updates results in failur
On Tue, Oct 24, 2017 at 8:46 PM, Aishwarya Nirmal wrote:
> I am working on a Touch Bar Web API that would allow websites to customize
> touch bar controls. There is currently no web standard for an interface like
> the touch bar, so my plan is to experiment with this feature and gather
> feedback
On Thu, Mar 1, 2018 at 7:44 PM, Michael Catanzaro wrote:
> It'd still be great to get some details about your strategy for mitigating
> user tracking via HSTS.
FWIW, some were posted by John Wilander at
https://mailarchive.ietf.org/arch/msg/websec/t_R00ZDVHrBmroEX989GeaXdejE.
--
https://anneva
On Thu, Apr 26, 2018 at 12:30 PM, Ricky Young wrote:
> I read the report and still find it hard to understand, if "User Agent
> sniffing is a terrible way to determine whether a browser supports certain
> features", what is the correct way of doing it?
https://developer.mozilla.org/en-US/docs/L
On Fri, Aug 21, 2020 at 2:41 AM Ryosuke Niwa wrote:
> I feel like I saw some discussions of also differentiating based on
> protocol (treating http://webkit.org and https://webkit.org
> differently). Do you know you've already had such a discussion and if
> so what the outcome of that discussion w
Hi,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 could use input
from the WebKit community, in particular DOM/JavaScript experts. I
recommend reading through
http://lists.w3.org/Archives/Public/www-dom/2012OctDec/thread.html#msg143
and
https://mail.mozilla.org/pipermail/es-discuss/2012-De
On Fri, Jan 25, 2013 at 12:21 AM, Geoffrey Garen wrote:
> Anne, can you help me get those comments sent to the w3 list? I sent them
> myself, but they seem to be held up or bounced?
Hey, I think they did make it, and Boris replied:
http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0068.html
On Wed, Nov 20, 2013 at 9:20 AM, Ryosuke Niwa wrote:
> HTMLTemplateElement has been shipped by Chrome and Firefox for a while
> and the specification has been quite stable at this point:
> http://www.w3.org/TR/html-templates/
That specification has issues and is effectively obsolete. I recommend
On Mon, May 19, 2014 at 10:33 AM, youenn fablet wrote:
> While looking at http://webkit.org/b/126619, a question came to my mind on
> user credentials prompting for cross-origin resources.
> WebKit allows prompting users for credentials in case of loading
> cross-origin resources (except for XHR).
On Fri, Jun 13, 2014 at 9:53 AM, Ryosuke Niwa wrote:
> I think Phil and Ben are suggesting to implement these types in JSC like we
> did for typed arrays.
If you were to do that you probably want to ping TC39 this time around.
--
http://annevankesteren.nl/
_
On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa wrote:
> What I'm saying is that we can implement it in JavaScriptCore for
> performance and we still make it look like a regular DOM object with
> wrappers to preserve the semantics.
I understand that, but given that it is in the JavaScript engine a
On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa wrote:
> I understand your concern and sentiment but I'm having a hard time imagining
> what kind of problems/concerns would TC39 have with these interfaces that
> are clearly prefixed with DOM.
That if they end up as objects in JavaScript engines th
Could this thread maybe be moved to es-discuss?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
On Fri, Oct 31, 2014 at 12:02 AM, youenn fablet wrote:
> I would like to add support for the streams API, starting
> with readable streams and their integration with XHR and loaders.
> This work is expected to happen behind a flag.
There's no planned integration with XMLHttpRequest.
--
https:/
On Fri, Oct 31, 2014 at 9:07 AM, Benjamin Poulain wrote:
> Any opinion for or against Streams? Do you know if Mozilla intends to
> implement it?
I'm in favor of having IO streams :-) There's so many features that
could be made better by having them. I don't think anyone from Mozilla
has looked at
On Sun, Nov 2, 2014 at 2:56 PM, youenn fablet wrote:
> Meaning that only the fetch API would at some point support streams?
> If so, I wonder why we should postpone a small but useful feature to a
> nice but future API.
I suspect there will be many APIs that support streams. It's been a
sorely mi
d
them. The only reason the W3C is not hosting this test suite at the
moment is because they cannot handle server-side scripts on the test
server at the moment. PLH is looking into a solution on their side as
I understand things.
--
Anne van Kesteren
http://an
nges to the specification really
ought to happen on public-weba...@w3.org.
Cheers,
--
Anne van Kesteren
http://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
FWIW, Opera is planning to ship this unprefixed.
http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
In general I think versioning is a bad idea, but out-of-band is even
worse. We'd have to change Web Workers (both constructors and
importScripts() would need to take some kind version-related
information) and everyone on the platform would instead of simply
using
On Wed, Mar 23, 2022 at 6:19 PM Patrick Griffis via webkit-dev
wrote:
> I'd like a position on CORB and intend to implement it in the future.
> This is already part of the Fetch Standard[0] and should be relatively
> straightforward.
>
> It effectively blocks cross-origin requests for resources th
Heya,
I would like to propose a lightweight process so we can jointly arrive on
position: labels on https://github.com/WebKit/standards-positions that can then
be considered somewhat final, modulo new information coming to light. Agreeing
on these positions as a community is important as they a
Heya,
Now that GitHub needs are addressed through a github field in
contributors.json and WebKit moved from IRC to Slack, is there still a
need for the nicks field?
Based on a suggestion on Slack I'm thinking of removing it from
https://webkit.org/team/ and I might as well clean up
contributors.j
On Mon, Oct 24, 2022 at 11:07 PM Darin Adler wrote:
> If they were consistently the Slack nicknames. But they often aren’t! The
> nicknames currently in there don’t necessarily match the Slack ones and
> obviously don’t match the GitHub account names. I wish these were more
> explicit about wha
On Tue, Jan 24, 2023 at 11:00 AM Myles Maxfield via webkit-dev
wrote:
> What do you think?
What this immediately made me think of is that Web IDL and the web
platform at large use unsigned and signed integers of various types.
And as those have different value spaces you'd notice if you do
someth
To reduce the overhead of switching between projects with different
whitespace requirements, I would like to suggest we start being
lenient when trailing whitespace is removed. In particular when a file
is being changed to fix a bug.
I could see going even further and enforcing this via the style
On Wed, Apr 12, 2023 at 7:20 PM Yusuke Suzuki via webkit-dev
wrote:
> I agree that we should not do it because it pollutes change history of files,
> git-blame results, and review-diff in PR.
> But at the same time, I think there is no reason to add a new trailing
> whitespace via a new commit.
I had a [[fallthrough]] patch, but internal C code got in the way:
- https://en.cppreference.com/w/c/language/attributes/fallthrough
- https://bugs.webkit.org/show_bug.cgi?id=265789
Using them directly where we can seems nice for (new) readers of the code at
least. Not sure what a macro for [[fa
On Wed, Feb 21, 2024 at 4:19 PM Dustin Mitchell via webkit-dev
wrote:
> We are working to ship a new client hint, form-factor, in Blink. Please let
> us know if you have any questions or comments.
>
> You can check the following documents for details:
> *
> https://github.com/djmitche/web-explai
41 matches
Mail list logo