Re: [webkit-dev] Request for position on the Origin-Isolation header

2020-08-21 Thread Anne van Kesteren 
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 was?

The scheme is already part of an origin so that is definitely a
boundary for this feature. However, I guess you're asking about the
"normal" website security boundary, which is site (roughly scheme +
registrable domain, exact definition in HTML). Site historically
lacked scheme, but that was changed. There are still some features
(primarily cookies) that compare sites and ignore the scheme (this
operation is also defined in HTML), but those too have proposals to
move away from that.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New iOS versions sending bogus User-Agent build data

2018-04-26 Thread Anne van Kesteren 
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/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection

Hope that helps,


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] HSTS user tracking

2018-03-02 Thread Anne van Kesteren 
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://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Touch Bar Web API

2017-10-25 Thread Anne van Kesteren 
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 that can inform a web standard.
>
> We have a fairly solid plan for how we want to go forward with this. We are
> planning to make use of the existent menu and menuitem tags to define the
> touch bar and touch bar items, respectively. The menu will be recognized as
> a touch bar menu if it has the type attribute “touch-bar”, and its contents
> would be rendered in the touch bar.
>
> I will be posting and landing patches under an experimental feature flag.
> The umbrella bug on Bugzilla can be found here:
> https://bugs.webkit.org/show_bug.cgi?id=178736 .

Heya, I'd appreciate it if you could give the HTML Standard community
a heads up about using the "touch-bar" value. Seems reasonable at
first glance, but would be nice to ensure nobody gets surprised:
https://github.com/whatwg/html/issues/new.

Thanks,


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where do we put WPT tests to be exported

2017-05-19 Thread Anne van Kesteren 
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 failures those end up
being tracked as new bugs. I realize that's not how it works today,
but that's how it should work I think.


> The same applies to deprecated features for which WPT tests might be removed
> for instance.

In this case it's expected that a "historical" test is added that
tests the feature isn't supported, so there's still coverage.


> I don't know what WPT can do there. This issue is probably limited in
> practice.

Modifying tests doesn't happen often, but it definitely does happen
and it would be nice if infrastructure accounted for it. (I've often
added additional assertions or additional tests to an existing
resource.)


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-16 Thread Anne van Kesteren 
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 clarify why what makes sense for WebKit,
might not make sense for tests designed to run on all engines. If
that's not desired here, I'll stop.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-15 Thread Anne van Kesteren 
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 work due to file URL restrictions. And you
>> can't guarantee that something will work from a file URL, because
>> there's no agreement on what will.
>
> That's not an issue with most ref or testharness.js tests which tests
> WebIDL, CSS OM, etc... because none of them have to do network
> requests.

Regardless of the feature, there's no defined agreement on how it
should work when loaded from a file URL. A test author cannot divide
"this can load from a file URL" from "this needs to be loaded over
HTTP(S)". Except that loading over HTTP(S) always ought to work as
that much we've written down in standards.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-14 Thread Anne van Kesteren 
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 
> tests referenced testharness.js via relative path, then most of the time they 
> could be loaded as local files just fine, which would be more convenient (as 
> well as, I believe, solving the "external trac link" issue).

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 work due to file URL restrictions. And you
can't guarantee that something will work from a file URL, because
there's no agreement on what will.

I personally just keep web-platform-tests running and don't notice
much overhead (MacBook Air, Mid 2012).


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Anne van Kesteren 
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 some kind of stability check in both
Chrome and Firefox (run the new tests 10 times and fail if the results
are inconsistent). Ideally Safari is added to that mix, though I think
the last time folks looked into that it wasn't possible for some
reason. That might be something to put some resources on.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-12 Thread Anne van Kesteren 
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 that those reviewing WPT changes
have some familiarity with the structure of WPT.


> What's to stop 4 vendors from upstreaming similar but non-identical tests for 
> a given feature?

Usually when a new feature is in development developers from the
various vendors use the relevant standards forum to coordinate on
testing and avoid duplication.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Another WPT bite

2017-05-11 Thread Anne van Kesteren 
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 actively maintained test
suite. Treating it as a dumping ground would be a mistake I think.

For WHATWG standards we make sure to update corresponding tests for
each change to the standard as well at which point any needed cleanup
occurs (we didn't start out with this process unfortunately so there's
definitely some cleanup left to be done here and there, but that's
true for each software project).


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] First stab at exporting tests to WPT

2017-03-22 Thread Anne van Kesteren 
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.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Removal of mediagroup/MediaController from HTML

2015-10-01 Thread Anne van Kesteren 
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
problematic or if the WHATWG is forgetting something.

Thank you,


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

2015-05-22 Thread Anne van Kesteren 
On Fri, May 22, 2015 at 1:50 PM, Gyuyoung Kim gyuyoung@webkit.org 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 isProtocolHandlerRegistered are supported
 as optional.

  https://bugs.webkit.org/show_bug.cgi?id=92749

Quickly scanning the bug I couldn't figure out whether you added hooks
to HTML's navigate algorithm or Fetch' fetch algorithm. In particular,
see the discussion in this bug:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

My personal opinion is that these schemes should only have an effect
if you navigate to them, not if you fetch them (the latter should
result in a network error in my opinion).


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

2015-05-22 Thread Anne van Kesteren 
On Fri, May 22, 2015 at 6:43 PM, Gyuyoung Kim gyuyoung@webkit.org 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 through the patch. As far as I know, Chrome also has
 similar implementation.

Okay, so

  img src=mailto:...

results in a network error and not a fetch to the registered URL?


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

2015-05-21 Thread Anne van Kesteren 
On Fri, May 22, 2015 at 1:25 AM, Anders Carlsson ander...@apple.com 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 good conversation for 
 webkit-dev.

 I agree with Sam.

So what else should web-based email or IRC clients or some such use to
integrate with sites that offer mailto and irc URLs? Especially for
email it seems like a worthwhile thing to solve. And that there's no
cross-browser way to do it in 2015 is somewhat of a shame.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

2015-05-21 Thread Anne van Kesteren 
On Fri, May 22, 2015 at 12:26 PM, Maciej Stachowiak m...@apple.com 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.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Streams API

2014-11-02 Thread Anne van Kesteren 
On Sun, Nov 2, 2014 at 2:56 PM, youenn fablet youe...@gmail.com 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 missing building block. And fetch() is not a future API. It's
being implemented now in both Blink and Gecko.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Streams API

2014-10-31 Thread Anne van Kesteren 
On Fri, Oct 31, 2014 at 9:07 AM, Benjamin Poulain benja...@webkit.org 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 https://streams.spec.whatwg.org/ in detail, but I could
be mistaken. If I find out I'll let you know.


-- 
https://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] SIMD support in JavaScript

2014-09-28 Thread Anne van Kesteren 
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

Re: [webkit-dev] Implement Geometry Interfaces

2014-06-13 Thread Anne van Kesteren 
On Fri, Jun 13, 2014 at 9:53 AM, Ryosuke Niwa rn...@webkit.org 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/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implement Geometry Interfaces

2014-06-13 Thread Anne van Kesteren 
On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org 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 at
that point, they cannot realistically standardize on a different
abstraction later on. And I got the impression typed arrays caught
them off guard, so giving them a heads up this time around might be
good.


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

Re: [webkit-dev] Implement Geometry Interfaces

2014-06-13 Thread Anne van Kesteren 
On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa rn...@webkit.org 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 they end up
leaking outside of browsers affecting other parts of the JavaScript
ecosystem. (And actually, we do run new APIs by TC39 for review, so if
these have passed for review on public-script-co...@w3.org, perhaps
calling out this implementation tactic, that might be sufficient.)


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

Re: [webkit-dev] CORS and user credentials prompting

2014-05-22 Thread Anne van Kesteren 
On Mon, May 19, 2014 at 10:33 AM, youenn fablet youe...@gmail.com 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).

Having just an exception for XMLHttpRequest seems very strange to me.
In the normal same-origin case both XMLHttpRequest and img prompt,
so if CORS is enabled I would expect both not to prompt.

(In general we should more closely investigate where we can avoid
prompting and just return the 401 as it's a source of very confusing
end user UI.)


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

Re: [webkit-dev] Enabling HTMLTemplateElement by default

2013-11-21 Thread Anne van Kesteren 
On Wed, Nov 20, 2013 at 9:20 AM, Ryosuke Niwa rn...@webkit.org 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
reading the bits about template in http://whatwg.org/C


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

Re: [webkit-dev] DOM methods that affect [[Prototype]]

2013-01-25 Thread Anne van Kesteren 
On Fri, Jan 25, 2013 at 12:21 AM, Geoffrey Garen gga...@apple.com 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

Unfortunately I do not know the details of the compatibility story.
I'm just trying to work out what the specification should say.

(There can be delay with archiving your email on the W3C site when
posting to W3C lists if you never posted with the email address
before, since you need to approve that your messages will be archived
and that might take some time to be fully processed.)


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

[webkit-dev] DOM methods that affect [[Prototype]]

2013-01-24 Thread Anne van Kesteren 
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-December/thread.html#27401
to some extent first. In particular the discussion is about what
happens to the [[Prototype]] of objects when objects are adopted and
when document.open() is invoked. Both Gecko and IE mutate the
[[Prototype]] and the tentative plan therefore is to align the
standard with that.

To make sure your feedback is fully considered by all parties raise it
via the bug or www-...@w3.org.

Thanks,


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

Re: [webkit-dev] JavaScriptCore and ES6

2011-12-16 Thread Anne van Kesteren 
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 script have to resort back to specifying the type attribute
again. We just got rid of that!
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Vendor Prefixing, was Re: New feature announcement - Implement HTML5 Microdata in WebKit

2011-09-26 Thread Anne van Kesteren 
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

Re: [webkit-dev] XHR responseArrayBuffer attribute

2010-09-27 Thread Anne van Kesteren 
(I'm subscribed to webkit-dev with a different address.)

On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman micha...@google.com wrote:
 Yes, if we go with telling xhr up front for the array buffer case, I guess
 an enum would be slightly better.

I do not think this should be told up front. You already need to keep
the octet buffer in memory for overrideMimeType to work the way it
does. We designed responseBlob as an optimization so you would not
have to deal with the other types. I do not think you can optimize the
reverse with the design as it stands today.

In any event, any discussion on changes 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

Re: [webkit-dev] Testing XHR

2010-09-21 Thread Anne van Kesteren 
On Tue, Sep 21, 2010 at 8:43 AM, Alexey Proskuryakov a...@webkit.org wrote:
 I don't think that the suite is testing much besides what we already have
 regression tests for. For the most part, it just has different expectations.

FWIW, if you find cases the test suite is missing I'm happy to add
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://annevankesteren.nl/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev