Re: [webkit-dev] Support "registerProtocolHandler" in WebKit2

2020-04-20 Thread Frédéric Wang
Hi,

I'm just bumping this old thread, not because I plan to implement it but
because I was mentioning it on slack the other day and realized not
everybody is #standards:

https://webkit.slack.com/archives/CTY7Z24RZ/p1587142539064000

In particular, my question was related to safelist VS blocklist
discussion from https://github.com/whatwg/html/issues/3998

From the slack replies as well as
https://lists.webkit.org/pipermail/webkit-dev/2019-November/030967.html
it seems a complete switch to blocklist is not the option preferred for
WebKit (if we ever decide to implement this API) so that's what I
commented on the spec / blink-dev discussions.

-- 
Frédéric Wang


On 04/07/2015 19:24, Sam Weinig wrote:
> (Sorry, had this sitting in my drafts).
>
> My concern with the registerProtocolHandler() API is that it complicates an 
> already the very complicated area of custom protocols and a good 
> implementation requires configuration UI (to choose which of potentially 
> multiple apps/websites you want a specific protocol to go to) that I am not 
> sure users are in the position make.  
>
> That, coupled with the small existing usage on the web and very few (if any) 
> reports from developers that they want this, leads me to think it isn’t a 
> good API for us to support.
>
> From an implementation perspective I also have concerns.  How is this should 
> the registration data be managed? Can it fit in the WebSiteData model we are 
> using for other data? Does it account for non-persistent sessions?  And 
> lastly, can we get the code size of supporting a feature like this to be 
> smaller?   
>
> - Sam
>
>> On Jun 7, 2015, at 5:39 PM, Darin Adler  wrote:
>>
>> Are we making progress in this discussion?
>>
>> Maciej stated that he thinks this is useful for mailto and I think that 
>> Gyuyoung Kim and Michael Catanzaro stated that they want to do this.
>>
>> As one next step in the discussion, is there anyone that wants to present a 
>> use case for a protocol other than mailto?
>>
>> Sam, Anders, you haven’t replied to the thread since Maciej made his remarks 
>> two weeks ago. He asked what you dislike about the API.
>>
>> — Darin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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


Re: [webkit-dev] Switching to XCBuild for Apple builds

2020-04-02 Thread Frédéric Wang
On 02/04/2020 04:42, Keith Rollin wrote:
>
> The patch was just on my local system. I wanted to make sure I’d covered any 
> issues that were turned up in response to my email before posting. But I’ve 
> now created the bug noted above and added the patch to it.
>
Thanks for publishing it. I assume by "Apple builds" (in the title) you
mean macOS and iOS ports i.e. it still works for people using the public
SDK rather than Apple's internal one. I gave a quick try and I'm not
able to build both ports in parallel anymore (will follow-up issues on
the bug).

I'm generally working with the latest version of Xcode and with the
command line, so I guess others are in better position to reply to your
concern on legacy support.

-- 
Frédéric Wang


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


Re: [webkit-dev] Switching to XCBuild for Apple builds

2020-04-01 Thread Frédéric Wang
On 31/03/2020 08:42, Keith Rollin wrote:

Hi,

> Hi all,
>
> For several years now, Xcode has included two build systems: the “legacy” 
> build system and the newer “XCBuild” system (see, for example, 
> <https://developer.apple.com/videos/play/wwdc2018/408/> and 
> <https://developer.apple.com/videos/play/wwdc2018/415>, as well as 
> <https://medium.com/xcblog/xcode-new-build-system-for-speedy-swift-builds-c39ea6596e17>
>  and 
> <https://medium.com/xcblog/five-things-you-must-know-about-xcode-10-new-build-system-41676cd5fd6c>).
>
> WebKit is finally in a position to move to the new build system. However, 
> this switch is not without consequences. In particular, WebKit has a 
> complicated build process and requires new XCBuild features only found in 
> Xcode 11.4. If you build from within the IDE, you will need Xcode 11.4 or 
> later. Pre-releases have been available for some time on developer.apple.com, 
> but the final version of Xcode 11.4 was posted to the Mac App Store last week 
> on March 24, 2020.

Out of curiosity, what will be the benefits brought by XCBuild for
WebKit developers? (sorry for asking but I don't have time to watch the
videos and skimming over the blog post, it seems it's mostly performance
improvement for swift compilation?)

> When building from the command line, the conditions are less strict. By 
> default, builds are performed with XCBuild if the `build-webkit` script or 
> the makefiles detect that Xcode 11.4 or later is installed. If not, builds 
> are performed with the legacy build system. We can be flexible here because 
> the build process is controlled by these scripts and makefiles, allowing the 
> build process to determine the Xcode version before invoking `xcodebuild`. 
> There is no such opportunity when building within the Xcode IDE, and so the 
> build requirements are stricter.
>
> I’ve made the changes to switch over to XCBuild but I haven’t yet posted 
> them. I want to first find out if this move will cause any issues for 
> developers who — for whatever reason — need to stay on old versions of Xcode. 
> If so, please let me know.
So I'm not sure I understand but concretely, am I already using the new
system if I use the build-script, I've upgraded to XCode 11.4 and
rebuilt WebKit from scratch? How can I know which build system I'm using?

Or do you mean you have a patch for WebKit that is pending to land? If
so, what's the bug number?

Thanks,

-- 
Frédéric Wang


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


[webkit-dev] Support for scrolling=off and scrolling=noscroll

2020-03-17 Thread Frédéric Wang
The spec
<https://html.spec.whatwg.org/multipage/rendering.html#the-page> says that
iframe and frame elements have a "scrolling" attribute that can be set
to "no", "off", or "noscroll" to disable scrollbars. Until now, WebKit
has only supported the "no" value but I opened
https://bugs.webkit.org/show_bug.cgi?id=208570for the remaining ones.

Gecko supports both and intent-to-ship was sent for Chromium too:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/qBQCKhzbIRc/RsfZQmf3AQAJ

-- 
Frédéric Wang

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


Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features

2020-02-27 Thread Frédéric Wang
Hi Ryosuke, just replying quickly to two points:

On 27/02/2020 08:08, Ryosuke Niwa wrote:
>
> Or do you mean that we enabling new feature / behavior by default? If
> so, then making such an announcement on webkit-dev requirement for Web
> facing feature / behavior change makes sense to me. But we should
> never use term such as "shipping".

Yes, it's about enabling the feature by default, as I said it's up to
the port maintainer to later decide whether they want to disable it. The
term "shipping" was copied from Mozilla's template but we can use
something else if that's misleading.

>
> 4. If there's no negative feedback, ship (ports maintainer can
> still disable the feature if they want to).
>
>
> We should probably adopt the same 5 business day policy here.

Right, the proposal says + 1 week, but that's just an example.

-- 
Frédéric Wang

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


[webkit-dev] Proposal for an "intent to" process for web-exposed features

2020-02-26 Thread Frédéric Wang
Hi,

The idea of an "intent to" process has been raised several times in the
past(e.g. in our 2020 goals [1])and some people already use it
informally, but it does not seem that we have any agreement right now.
Such a process would help to coordinate changes internally (between port
maintainers and contributors) and externally (with standard groups,
users and other implementers). For the former point, see [2][3][4] for
examples of how coordination is not smooth right now.The latter point
will give a better understanding of what's happening in WebKit and help
web developer advocacy.

The Mozilla and Chromium projects have their own process [5] [6]. We can
probably start with minimal rules and refine them in the future. We can
even make it mandatory only for new web platform features developed
under a runtime preference for now (i.e. excluding small features for
which it's not worth introducing a flag, behavior changes or
deprecation/removal). Below is a proposal based on Mozilla's one.

WDYT?

Frédéric, on behalf of Igalia's web platform team

[1] https://trac.webkit.org/wiki/WebKitGoalsfor2020
[2] Behavior change: https://bugs.webkit.org/show_bug.cgi?id=201641#c49
[3] Deprecation/Removal: https://bugs.webkit.org/show_bug.cgi?id=204125#c7
[4] New feature: https://bugs.webkit.org/show_bug.cgi?id=157743landed in
April 2019 and only enabled in
https://bugs.webkit.org/show_bug.cgi?id=203644
[5] https://wiki.mozilla.org/ExposureGuidelines
[6] https://www.chromium.org/blink/launching-features



I/ General process

1. Email webkit-dev with an intent to prototype.
2. Implement the feature normally behind a off-by-default preference.
3. Email webkit-dev with an intent to ship.
4. If there's no negative feedback, ship (ports maintainer can still
disable the feature if they want to).

II/ Intent to prototype template

Subject: Intent to prototype:  

Summary: Elevator pitch for the new functionality.
Bug: Link to https://bugs.webkit.org
Standard: Link to standard or public discussions with other browser vendors.
Preference: name of flag.
Status in other browsers: "shipped", "intent emailed" or "considering".
web-platform-tests: Test suite for this feature.

III/ Intent to ship template

Subject: Intent to ship:  

As of  I intend to turn  on by default:
https://bugs.webkit.orgto turn the flag on>. This has
originally been proposed in https://lists.webkit.org/pipermail/webkit-devintent to prototype>.*If
anything changed since that thread please include that information in
this email*.

It's acceptable to merge the "intent to prototype" into the "intent to
ship" email as long as all the relevant requirements are met.

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


[webkit-dev] [Intersection Observer] Accept a Document as an explicit root

2020-02-23 Thread Frédéric Wang
Hello,

This email is to announce that Igalia has started to implement a recent
enhancement to Intersection Observer, that allows users to specify a
Document as an explicit root. The typical use case is when such a
Document is the one of an iframe. Below is some documentation:

WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=208047
W3C issue: https://github.com/w3c/IntersectionObserver/issues/372
Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1617154
(intent-to will follow)
Chromium bug:
https://chromium-review.googlesource.com/c/chromium/src/+/2003750

-- 
Frédéric Wang

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


Re: [webkit-dev] Calculate img/video aspect ratio from width and height HTML attributes

2020-02-18 Thread Frédéric Wang
On 19/12/2019 14:22, Frédéric Wang wrote:
> Hello,
>
> In  [1], we will try and make WebKit rely on the width and height HTML
> attributes of the  and  elements in order to determine their
> aspect ratio, so that it can be used for sizing the image using CSS,
> before the content loads.
>
> HTML and CSS standardization groups already reached consensus on this
> proposal [2] and there are WPT tests for it. Moreover this is already
> shipped in Gecko [3] and Chromium [4].
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=201641
> [2] https://github.com/WICG/intrinsicsize-attribute/issues/16
> [3]
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/H9j3aJ20IgE/fs9Df3loCQAJ
> [4]
> https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Compute$20img$2Fvideo$20aspect$20ratio$20from$20width$20and$20height$20HTML$20attributes%7Csort:date/blink-dev/GePU9T8UpEc/uQWhDZeODwAJ
>
Hi,

Just for completeness, we intend to enable the flag by default in

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

-- 
Frédéric Wang

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


Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API

2020-02-13 Thread Frédéric Wang
On 10/12/2019 17:52, Frédéric Wang wrote:
> Hi everybody,
>
> Cathie has taken over my work on this. In order to facilitate review,
> we decided to split the patch into three parts. If there is no
> opposition, we'll probably go ahead and land (1) and (2) below. But in
> any case, we need approval from Apple reviewers on (3).
>
> (1) Introduce CSS/IDL changes under a new preference flag
>     https://bugs.webkit.org/show_bug.cgi?id=205009
>
>     I already r+ed this part and I think Simon Fraser had reviewed
> this part
>     before so I don't expect it to be controversial. The only question is
>     whether it makes sense to land this before the rest of the
> implementation
>     is done. I guess it is ok to take it with (2) in any case.
>
> (2) Implement a generic animator class running in the scrolling
> thread, based
>     on the one that already exists on GTK for smooth scrolling.
>     https://bugs.webkit.org/show_bug.cgi?id=204882
>
>     Simon has also partially reviewed this piece and modulo minor
> changes I
>     think it looks good to me too. The issue here is that I'm not sure
> I should
>     review it given I wrote most of this code. Also, it's probably not
> the most
>     efficient approach and ports should probably rely on any existing
>     platform API to animate scrolling when available. However, it is a
> necessary
>     fallback and the preference flag is turned off for now, so I think
> it is
>     safe to take this for now...
>
> (3) Implement scroll animator in the UI process for iOS, based on native
>     platform support (UIScrollView).
>     https://bugs.webkit.org/show_bug.cgi?id=204936
>
>     This part hasn't been reviewed yet although the general design has
> been
>     discussed with Simon. Alternatively, this patch can be taken
> before (2)
>     since the two are more or less independent and each one really
> only depends
>     on (1).
>
> I'm interested to hear about suggestions to rely on native scroll
> animations for other ports. However, this can probably be done in
> follow-up patches. Web developers really requested support on iOS and
> it seems very important to have (3) for that port.
>
> Thank you,

Hi,

As announced, parts (1) and (2) have landed and there does not seem to
have been any issue in the past week. We'll go ahead with part (3).

-- 
Frédéric Wang

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


[webkit-dev] Calculate img/video aspect ratio from width and height HTML attributes

2019-12-19 Thread Frédéric Wang
Hello,

In  [1], we will try and make WebKit rely on the width and height HTML
attributes of the  and  elements in order to determine their
aspect ratio, so that it can be used for sizing the image using CSS,
before the content loads.

HTML and CSS standardization groups already reached consensus on this
proposal [2] and there are WPT tests for it. Moreover this is already
shipped in Gecko [3] and Chromium [4].

[1] https://bugs.webkit.org/show_bug.cgi?id=201641
[2] https://github.com/WICG/intrinsicsize-attribute/issues/16
[3]
https://groups.google.com/forum/#!msg/mozilla.dev.platform/H9j3aJ20IgE/fs9Df3loCQAJ
[4]
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Compute$20img$2Fvideo$20aspect$20ratio$20from$20width$20and$20height$20HTML$20attributes%7Csort:date/blink-dev/GePU9T8UpEc/uQWhDZeODwAJ

-- 
Frédéric Wang

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


Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

2019-12-10 Thread Frédéric Wang
On 02/12/2019 21:22, David Bokan wrote:
> Hello webkit-dev,
>
> I'd like to solicit feedback as well as an official position from
> Webkit on our proposal for the text fragment
> directive: https://github.com/WICG/ScrollToTextFragment.
>
> In summary: this is a feature that allows authors and users to craft
> URLs to pages and specify a snippet of text on the page as a
> subresource (visually highlighting it and scrolling it into view).
> Analogous to element-id based fragment anchors but for text.
>
> You can try this out today in Chrome Beta by
> enabling chrome://flags/#enable-text-fragment-anchor. Here's an
> example link:
>
> https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#:~:text=An%20optional%20fragment,element%20into%20view
>
> Relevant Links:
>
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Explainer
> <https://github.com/WICG/ScrollToTextFragment/blob/master/README.md>
> Spec <https://wicg.github.io/ScrollToTextFragment/>
> TAG Review <https://github.com/w3ctag/design-reviews/issues/392>
> (Currently Suspended) Blink Intent Thread
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/NLbg84m0EAAJ>
> Issue on Mozilla standards-positions
> <https://github.com/mozilla/standards-positions/issues/194>
>
> We've been using the GitHub repo for issue tracking but happy to take
> feedback (official or otherwise) in any form.
>
> Thank you!
> David
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
Hi,

I think some of the webkit-dev members have already replied on the Blink
thread. Just to repeat here, I think the concerns Igalia had regarding
the lack of details to implement the algorithm have been addressed in
the latest versions of the spec. We haven't checked again if the WPT
coverage is good enough now though.

-- 
Frédéric Wang

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


Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API

2019-12-10 Thread Frédéric Wang
Hi everybody,

Cathie has taken over my work on this. In order to facilitate review, we
decided to split the patch into three parts. If there is no opposition,
we'll probably go ahead and land (1) and (2) below. But in any case, we
need approval from Apple reviewers on (3).

(1) Introduce CSS/IDL changes under a new preference flag
    https://bugs.webkit.org/show_bug.cgi?id=205009

    I already r+ed this part and I think Simon Fraser had reviewed this part
    before so I don't expect it to be controversial. The only question is
    whether it makes sense to land this before the rest of the
implementation
    is done. I guess it is ok to take it with (2) in any case.

(2) Implement a generic animator class running in the scrolling thread,
based
    on the one that already exists on GTK for smooth scrolling.
    https://bugs.webkit.org/show_bug.cgi?id=204882

    Simon has also partially reviewed this piece and modulo minor changes I
    think it looks good to me too. The issue here is that I'm not sure I
should
    review it given I wrote most of this code. Also, it's probably not
the most
    efficient approach and ports should probably rely on any existing
    platform API to animate scrolling when available. However, it is a
necessary
    fallback and the preference flag is turned off for now, so I think it is
    safe to take this for now...

(3) Implement scroll animator in the UI process for iOS, based on native
    platform support (UIScrollView).
    https://bugs.webkit.org/show_bug.cgi?id=204936

    This part hasn't been reviewed yet although the general design has been
    discussed with Simon. Alternatively, this patch can be taken before (2)
    since the two are more or less independent and each one really only
depends
    on (1).

I'm interested to hear about suggestions to rely on native scroll
animations for other ports. However, this can probably be done in
follow-up patches. Web developers really requested support on iOS and it
seems very important to have (3) for that port.

Thank you,


On 14/11/2018 19:58, Frédéric Wang wrote:
> Hi all,
>
> The main implementation is now submitted for review at:
> https://bugs.webkit.org/show_bug.cgi?id=188043
>
> It has some issue with smooth scrolling via scrollIntoView on nested
> scrollers but I don't plan to work on this until the main part is
> merged. See https://bugs.webkit.org/show_bug.cgi?id=189907
>
> On 20/09/2018 22:26, Frédéric Wang wrote:
>> Hi all,
>>
>> This email is to announce that I have started to work on (programmatic)
>> smooth scrolling in WebKit from the CSSOM View specification [1]. To use
>> this effect, web developers can pass a behavior parameter (auto, smooth,
>> or instant) to Element.scroll, Element.scrollTo, Element.scrollBy,
>> Element.scrollIntoView, Window.scroll, Window.scrollTo or
>> Window.scrollBy [2]. When behavior is auto, the instant/smooth
>> characteristic is actually taken from the value of a new CSS
>> scroll-behavior property [3]. This new feature will be protected by a
>> compile flag (enabled by default) and a runtime flag (an experimental
>> feature). If you are interested, you can follow advancement on Bugzilla [4].
>>
>> Incidentally (and since that was convenient to do it before) I also
>> added some basic support for new ScrollIntoView options [5] [6] that
>> allow to specify how you want the revealed element to be aligned with
>> respect to its scrollable ancestors.
>>
>> Cheers,
>>
>>
>> Frédéric
>>
>> [1] https://drafts.csswg.org/cssom-view
>> [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions
>> [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
>> [4] https://bugs.webkit.org/show_bug.cgi?id=188043
>> [5] https://bugs.webkit.org/show_bug.cgi?id=189258
>> [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>

-- 
Frédéric Wang

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


Re: [webkit-dev] Supporting for finding ref tests

2019-11-12 Thread Frédéric Wang
On 12/11/2019 20:06, Simon Fraser wrote:
>> On Nov 12, 2019, at 4:52 AM, Frédéric Wang  wrote:
>>
>> On 09/11/2019 04:02, Ryosuke Niwa wrote:
>>>>>>  - Requires us modifying each port's DRT to support this format
>>>>>>
>>>>>> No, it just requires webkitpy hacking which I've done in the patch.
>>>>> I'm not certain writing a bunch of regular expressions in webkitpy is
>>>>> a reliable mechanism to find expected results. Another issue I found
>>>>> back then was that it significantly slowed run-webkit-tests' startup
>>>>> time because WPT has a workflow to find all tests & their expected
>>>>> results upfront before any tests could run.
>>>> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, 
>>>> and our importer use to find the ref tests.
>>>>
>>>> We don't find references up-front; only when running each test. This patch 
>>>> does add some overhead for parsing each test file,
>>>> which I measured to be about 1-2 sec on a directory which took 30s to run. 
>>>> I think this slight slowdown is worthwhile (we could
>>>> probably eliminate it with some webkitpy optimizations).
>>> Hm... that's ~3% overhead.
>> @Simon: I agree with Ryosuke that 3% sounds big. IIUC you are parsing
>> the HTML file when running each test? I thought that there is a
>> MANIFEST.json file which is supposed to cache that information, why
>> can't we use it?
> I don't see any files call MANIFEST.json in the wpt repo.

This is a generated file:
https://github.com/web-platform-tests/wpt/blob/7c50c216081d6ea3c9afe553ee7b64534020a1b2/tools/runner/update_manifest.py#L12

-- 
Frédéric Wang

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


Re: [webkit-dev] Supporting for finding ref tests

2019-11-12 Thread Frédéric Wang
On 09/11/2019 04:02, Ryosuke Niwa wrote:
>
>>>>   - Requires us modifying each port's DRT to support this format
>>>>
>>>> No, it just requires webkitpy hacking which I've done in the patch.
>>> I'm not certain writing a bunch of regular expressions in webkitpy is
>>> a reliable mechanism to find expected results. Another issue I found
>>> back then was that it significantly slowed run-webkit-tests' startup
>>> time because WPT has a workflow to find all tests & their expected
>>> results upfront before any tests could run.
>> The patch uses html5lib (via BeautifulSoup), which is exactly what WPT, and 
>> our importer use to find the ref tests.
>>
>> We don't find references up-front; only when running each test. This patch 
>> does add some overhead for parsing each test file,
>> which I measured to be about 1-2 sec on a directory which took 30s to run. I 
>> think this slight slowdown is worthwhile (we could
>> probably eliminate it with some webkitpy optimizations).
> Hm... that's ~3% overhead.

@Simon: I agree with Ryosuke that 3% sounds big. IIUC you are parsing
the HTML file when running each test? I thought that there is a
MANIFEST.json file which is supposed to cache that information, why
can't we use it?

-- 
Frédéric Wang

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


Re: [webkit-dev] Implementing MathML stylistic attributes in WebKit

2019-09-03 Thread Frédéric Wang
On 02/09/2019 22:12, Ryosuke Niwa wrote:
>
> On Mon, Sep 2, 2019 at 7:11 AM Frédéric Wang  <mailto:fw...@igalia.com>> wrote:
>
>
> Currently MathML attributes mathvariant, displaystyle and
> scriptlevel [1] [2] are implemented in WebKit using custom "style
> resolution" and "one-glyph rendering" inside the MathML layout
> code [3] [4] [5]. These features involve text rendering and
> interaction with CSS font-size, so it is difficult to implement
> them properly and completely that way. There are known bugs and
> missing features right now (e.g. mathvariant transform only
> applies to one-character strings, automatic
> displaystyle/scriptlevel does not work with fractions, etc)
>
> Several years ago, Gecko used to do something similar but that was
> causing a lot of problems (dynamic update, assertion failures...).
> At the end, this is now implemented in Gecko more reliably by
> mapping the attributes to internal CSS properties ; [6] is based
> on that. When I tried to do something like this in WebKit three
> years ago, I was only able to rely on proprietary -webkit-*
> extensions exposed to users [7].
>
> So my questions are:
>
> (1) What is WebKit's mechanism to implement such stylistic attributes?
>
>
> It looks like -internal-text-autosizing-status is such a property.
> This is a property the author can never set and we set it internally
> for implementation purposes.
> ComputedStyleExtractor::valueForPropertyInStyle manually skips it so
> it's never exposed anywhere.
>
> One subtle thing I didn't check is whether it would affect the CSS
> parser or not (as in whether it would be considered as a valid CSS
> property or not). There might be some subtle effect there.
>
> -webkit-text-decorations-in-effect is also a CSS property we use
> internally to compute the effective set of text decorations applied to
> text for editing purposes. The author can never set it but it's
> unfortunately exposed via computed style. 
>
> (2) Is it possible to implement internal (i.e. not web-exposed to
> users) CSS properties/values in WebKit?
>
>
> It appears possible today using the technique deployed by
> CSSPropertyInternalTextAutosizingStatus.
>  
>
Thanks for the pointers! I think it is worth trying to (re-)implement
these MathML attributes using internal properties.

-- 
Frédéric Wang

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


[webkit-dev] Implementing MathML stylistic attributes in WebKit

2019-09-02 Thread Frédéric Wang
Hello,

Currently MathML attributes mathvariant, displaystyle and scriptlevel
[1] [2] are implemented in WebKit using custom "style resolution" and
"one-glyph rendering" inside the MathML layout code [3] [4] [5]. These
features involve text rendering and interaction with CSS font-size, so
it is difficult to implement them properly and completely that way.
There are known bugs and missing features right now (e.g. mathvariant
transform only applies to one-character strings, automatic
displaystyle/scriptlevel does not work with fractions, etc)

Several years ago, Gecko used to do something similar but that was
causing a lot of problems (dynamic update, assertion failures...). At
the end, this is now implemented in Gecko more reliably by mapping the
attributes to internal CSS properties ; [6] is based on that. When I
tried to do something like this in WebKit three years ago, I was only
able to rely on proprietary -webkit-* extensions exposed to users [7].

So my questions are:

(1) What is WebKit's mechanism to implement such stylistic attributes?

(2) Is it possible to implement internal (i.e. not web-exposed to users)
CSS properties/values in WebKit?

(3) Is it ok to add more -webkit-* properties/values or should these
properties be standardized at the CSS WG instead?

I understand answers to these general questions from other browser
project is either use internal properties or standardize them.

Thanks,

Frédéric

PS: For a concrete example, see [8]. Automatic mathvariant is used for
italic variables while font-size in fractions is calculated according to
displaystyle / scriptlevel rules. The latter is incorrect (check the
attached screenshot) while selection highlight is broken for the former.

[1] https://mathml-refresh.github.io/mathml-core/#the-mathvariant-attribute
[2]
https://mathml-refresh.github.io/mathml-core/#the-displaystyle-and-scriptlevel-attributes
[3]
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/css/mathml.css
[4]
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/MathMLStyle.cpp
[5]
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/rendering/mathml/RenderMathMLToken.cpp#L593
[6]
https://mathml-refresh.github.io/mathml-core/#css-extensions-for-math-layout
[7] https://bugs.webkit.org/show_bug.cgi?id=133845#c5
[8] https://bug-201242-attachments.webkit.org/attachment.cgi?id=377730

-- 
Frédéric Wang

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


Re: [webkit-dev] Remove SVGTests.hasExtension?

2019-06-10 Thread Frédéric Wang
On 10/06/2019 17:31, Maciej Stachowiak wrote:
>
> Since SVG WG resolved to remove it, has it in fact been removed from
> the SVG spec?

Right, compare SVG 2 (W3C Recommendation 04 October 2018):

https://www.w3.org/TR/SVG2/types.html#InterfaceSVGTests

and SVG 1.1 (W3C Recommendation 16 August 2011):

https://www.w3.org/TR/SVG11/types.html#InterfaceSVGTests/
/

-- 
Frédéric Wang

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


Re: [webkit-dev] Remove SVGTests.hasExtension?

2019-06-07 Thread Frédéric Wang
Patch for Firefox was uploaded 4 years ago and they announced plan for
removal at that time. We pinged Mozilla some weeks ago about it, they
landed the patch and announced it:

https://bugzilla.mozilla.org/show_bug.cgi?id=1133175
https://www.fxsitecompat.com/en-CA/docs/2019/hasextension-has-been-removed-from-some-svg-interfaces/
https://www.fxsitecompat.com/en-CA/docs/2015/several-properties-will-be-removed-from-svgsvgelement/

I didn't check Edge, but Microsoft is migrating to Chromium so that's
not going to be there in future versions.

On 07/06/2019 20:40, Ryosuke Niwa wrote:
> Does Edge support it? When did Firefox remove this feature?
>
> On Fri, Jun 7, 2019 at 1:55 AM Frédéric Wang  <mailto:fw...@igalia.com>> wrote:
>
> Hi,
>
> 4 years ago, the SVG WG resolved to remove SVGTests.hasExtension due to 
> lack of use and being a poor API.
> It was removed from Chromium at that time and has been removed from 
> Firefox recently.
>
> I'm not sure whether the WebKit community is willing to keep that 
> feature. Anyway I opened a bug entry to track possible removal: 
>
> https://bugs.webkit.org/show_bug.cgi?id=198652
>
> -- 
> Frédéric Wang
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> -- 
> - R. Niwa


-- 
Frédéric Wang

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


[webkit-dev] Remove SVGTests.hasExtension?

2019-06-07 Thread Frédéric Wang
Hi,

4 years ago, the SVG WG resolved to remove SVGTests.hasExtension due to lack of 
use and being a poor API.
It was removed from Chromium at that time and has been removed from Firefox 
recently.

I'm not sure whether the WebKit community is willing to keep that feature. 
Anyway I opened a bug entry to track possible removal: 

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

-- 
Frédéric Wang

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


Re: [webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)

2019-06-07 Thread Frédéric Wang
On 06/06/2019 19:00, Frédéric Wang wrote:
> On 06/06/2019 18:32, Dan Bernstein wrote:
>> When dyld aborts this way it logs the reason (based on the backtrace,
>> likely a missing symbol). You may be able to find the message from
>> dyld in the macOS Console app (the Simulator app also allows you to
>> open the Simulator system log, if I remember correctly).
> Thanks. Unfortunately, the macOS console does not contain much info.
>
> Here are possibly relevant errors in the simulator system log:
>
> Unknown key for Boolean: EnablePressuredExit
> Unknown key for Boolean: EnableTransactions
> Unknown key for integer: _DirtyJetsamMemoryLimit
> unsupported XPC object: OS_xpc_dictionary
>
> These are logged at initial launch though. I can't see anything
> particular when the page keeps crashing again and again.
>
I moved this discussion to https://bugs.webkit.org/show_bug.cgi?id=198646

-- 
Frédéric Wang

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


Re: [webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)

2019-06-06 Thread Frédéric Wang
On 06/06/2019 18:32, Dan Bernstein wrote:
>
> When dyld aborts this way it logs the reason (based on the backtrace,
> likely a missing symbol). You may be able to find the message from
> dyld in the macOS Console app (the Simulator app also allows you to
> open the Simulator system log, if I remember correctly).

Thanks. Unfortunately, the macOS console does not contain much info.

Here are possibly relevant errors in the simulator system log:

Unknown key for Boolean: EnablePressuredExit
Unknown key for Boolean: EnableTransactions
Unknown key for integer: _DirtyJetsamMemoryLimit
unsupported XPC object: OS_xpc_dictionary

These are logged at initial launch though. I can't see anything
particular when the page keeps crashing again and again.

-- 
Frédéric Wang

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


[webkit-dev] Cannot load pages with run-safari --ios-simulator (public SDK)

2019-06-06 Thread Frédéric Wang
_header
const*, int, char const**, long, macho_header const*, unsigned long*) + 1167
    frame #29: 0x0001053cc036 dyld`_dyld_start + 54

-- 
Frédéric Wang

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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-21 Thread Frédéric Wang
On 20/03/2019 20:45, Ryosuke Niwa wrote:
>
> I agree on the goal but disagree on the suggestion. At minimum, we
> should decide each case separately and try to collect some data before.
>
> We can continue to agree to disagree on this point. But I strongly
> object to removing any features from MathML implementation of
> WebKit without having done comprehensive compatibility testing
> with various iOS and macOS apps that use MathML.
>
I'm also happy with more testing with iOS / macOS apps. I was just
concerned by the "for now" and the "there isn't any easy way to do it"
in your initial emails, it seems you were not open to accept any change
for an undetermined period of time, just because of your ports...

> I guess one way to satisfy your desire without breaking WebKit
> in iOS and macOS would be to add a runtime feature flag which
> disables the parts of MathML that's not a part of core MathML,
> and then only enable this feature in your own port. That would
> allow you to have the same set of features between your
> products without breaking our ports.
>
>
...however that proposal from you last email sounds more constructive.
That would still be extra burden for us to manage deprecated MathML code
and the corresponding tests, but at least that will give us the
opportunity to start disabling features & run tests without them, to
better see which parts we can ignore when comparing code between web
engines and even to have beta testers providing feedback. So that seems
a good trade off until Apple is ready to accept the changes (or not).

> I really don't care what maintainers of Blink say or do about
> MathML because they don't have MathML implementation right
> now. My primary concern as I've stated multiple times is iOS
> and macOS apps that currently use MathML.
>
Again, you are the one who brought up that topic in this thread. If you
really don't care about Blink maintainers or Google's opinion then
please just don't mention them.

>> These all seem like something out in the wild might be
>> using. https://github.com/search?q=mathml+fontweight=Code yields
>> quite a few examples in which fontweight content attribute is
>> being used for example.
>
> MathML is used as an exchange format in various tools,
> standards and documents so that's not really surprising to get
> matches. However, the MathML Core spec targets usage in web
> engines so what we need instead is to check content that is
> actually served to web engines in general and to WebKit in
> particular.
>
> Note: There are straighforward CSS polyfills for the
> attributes previously mentioned. A JS polyfill would be needed
> for MathML nonzero unitless lengths (if they are really used)
> but removing the possibility to write "5" instead of "500%" is
> part of the general goal to align more with HTML/CSS.
> Regarding fontweight, it is known to require some extra
> code/tests in Gecko/Stylo in order to handle conflicts with
> mathvariant ( WebKit doesn't handle such conflicts
> 
> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
> ).
>
> An existence of a bug in our code is not an evidence that the
> entire feature can be removed.
>
That was not my point. I was just trying to explain that there are more
issues involved when you analyze carefully each case, you cannot just
rely on generic claims, quick searches or unilateral approaches in order
to make a decision. Anyway that was just a side note, it's probably not
worth entering into details on this mailing list.

Thank you,

-- 
Frédéric Wang

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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-20 Thread Frédéric Wang
On 16/03/2019 00:04, Ryosuke Niwa wrote:
> On Fri, Mar 15, 2019 at 3:33 PM Frédéric Wang  <mailto:fw...@igalia.com>> wrote:
>
> Hi Ryosuke and Myles,
>
> Thank you for your reply. First, the exact thing about what will
> be in MathML Core is still open, people are welcome to join and
> participate to the MathML CG [1] or comment on the GitHub tracker [2].
>
> Our plan was also to remove features from WebKit but of course
> ultimately the consensus has to be made in the WebKit community
> (hence our heads up email). What do you suggest? Should we send
> "intent to remove" to this mailing list?
>
>
> Ultimately, we need some testing to ensure whatever iOS and macOS
> apps, or websites that specifically target WebKit and Gecko that use
> MathML don't get broken by those removals. Because there isn't an easy
> way to do that right now, my suggestion is not remove any features for
> now.
>
I agree on the goal but disagree on the suggestion. At minimum, we
should decide each case separately and try to collect some data before.

> Put it another way, what's the benefit of removing features in WebKit
> before fixing other MathML bugs?

This question sounds rhetorical, but basically this is already said in
the initial email: improve browser interoperability and reduce
complexity of current implementations. Especially, at Igalia we are
working on several engines in parallel and it's much easier if the
implementation logic and set of WPT tests is consistent in order to
compare the code, fix bugs and implement new features. Maintaining
WebKits-specific features and tests would be an extra burden, so it
would be preferable to avoid it when possible.

> If the only benefit is that Blink may have an easier time implementing
> the rest and therefore might be more interoperable, I really don't buy
> that argument given MathML isn't supported at all in Blink today.

Note that you are the only one who suggested on this thread that our
WebKit announcement is made according to Google's opinion or Blink's
development plan... I get that having more features in Gecko/WebKit
might be an interoperability concern and maybe Apple actually has more
information from Google, but so far Google people actually seem more
interested in the two other points of the initial email.

FWIW, the removal/deprecation discussions are currently led by the
MathML Refresh CG (which include browser implementers from
Mozilla/Igalia, people from the former Math WG, scholars, publishers,
a11y experts, authors of MathML tools...) and rely heavily on the
experience from WebKit/Gecko/Stylo implementations.

> These all seem like something out in the wild might be
> using. https://github.com/search?q=mathml+fontweight=Code yields
> quite a few examples in which fontweight content attribute is being
> used for example.

MathML is used as an exchange format in various tools, standards and
documents so that's not really surprising to get matches. However, the
MathML Core spec targets usage in web engines so what we need instead is
to check content that is actually served to web engines in general and
to WebKit in particular.

Note: There are straighforward CSS polyfills for the attributes
previously mentioned. A JS polyfill would be needed for MathML nonzero
unitless lengths (if they are really used) but removing the possibility
to write "5" instead of "500%" is part of the general goal to align more
with HTML/CSS. Regarding fontweight, it is known to require some extra
code/tests in Gecko/Stylo in order to handle conflicts with mathvariant
( WebKit doesn't handle such conflicts
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/mathml/MathMLElement.cpp#L122
).

-- 
Frédéric Wang

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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-20 Thread Frédéric Wang
On 16/03/2019 00:29, Maciej Stachowiak wrote:
> It’s easier for us to check Apple Books and iOS App compatibility for
> a batch of possible removals at once, instead of one at a time. We can
> start by looking at the set of items below.
>
> It’s helpful to give a heads-up other than the normal review process,
> because our main concern is compatibility, and not all reviewers will
> be able to easily access the corpus of app-specific or books-specific
> content that may be affected. 
>
> We assume web compatibility is not a major issue since MathML isn’t in
> all browsers and in general is not widely used on websites, but there
> might also be some value in doing web usage analysis for these
> features if there’s any meaningful web usage of MathML at all.

We'll try to provide heads-up on this mailing list and will work with
the MathML Refresh CG in order to get more statistics. Having data from
Apple products would be very useful, here are some first questions (this
includes elements/attributes/values raised by the CG for
removal/deprecation but most have not been decided yet):

* Usage statistics for MathML elements used. More specifically, which of
the following elements are used: munder, mover, msub, msup, msubsup,
mlabeledtr, merror, mphantom, maction, mglyph, mfenced, mstyle, ms

* Usage statistics for MathML attributes. More specifically, which of
the following attributes are used: mathvariant, numalign, denomalign,
align (on munderover/munder/mover elements), bevelled, subscripshift,
superscriptshift, other, macros, mode, fontfamily, index, fontfamily,
fontweight, fontstyle, fontsize, color, background,
veryverythinmathspace, verythinmathspace, thinmathspace,
mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace

* Usage statistics for MathML attributes on the mstyle and math
elements. More specifically, do mstyle elements use any attribute other
than displaystyle, dir, mathsize, mathbackground, mathcolor,
mathvariant, scriptlevel?

* Attribute values. Is any of the following attribute used?
  - linethickness attribute with value "thin", "thick" or "medium"
  - mathsize attribute with value "small", "normal" or "big"
  - attribute with value a nonzero number without unit (e.g. "4") other
than scriptlevel
  - attribute with value "veryverythinmathspace", "verythinmathspace",
"thinmathspace", "mediummathspace", "thickmathspace",
"verythickmathspace" or "veryverythickmathspace".
  - notation attribute containing the value "radical" (e.g.
notation="radical circle")
  - attribute with leading or trailing white space characters (U+0020,
U+0009, U+000A, U+000D or U+000C). For example width=" 5em ".

* Trailing/leading whitespace in token elements (mi, mtext, mn, mo,
mtext, ms). Do token elements contain text content with leading or
trailing white space characters (U+0020, U+0009, U+000A, U+000D or
U+000C). For example  x .


Thanks,

-- 
Frédéric Wang


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


Re: [webkit-dev] MathML Refresh Heads up

2019-03-15 Thread Frédéric Wang
Hi Ryosuke and Myles,

Thank you for your reply. First, the exact thing about what will be in
MathML Core is still open, people are welcome to join and participate to
the MathML CG [1] or comment on the GitHub tracker [2].

Our plan was also to remove features from WebKit but of course
ultimately the consensus has to be made in the WebKit community (hence
our heads up email). What do you suggest? Should we send "intent to
remove" to this mailing list? Or is it enough to cc' Apple reviewers on
bugs in order to get the approval? Something else?

For now, these are the features the CG has already agreed to not include
in MathML Core (more to come). We would like to propose to remove them
from WebKit:

* "thin", "thick", "medium" values of mfrac's linethickness attribute (
https://github.com/mathml-refresh/mathml/issues/4)
* "small" "normal" "big" values of mathsize attribute (
https://github.com/mathml-refresh/mathml/issues/7)
* nonzero unitless values for MathML lengths (
https://github.com/mathml-refresh/mathml/issues/24)
* fontfamily, fontweight, fontstyle, fontsize, color, background MathML
attributes ( https://github.com/mathml-refresh/mathml/issues/5)

In any case, it would be very appreciated to get some analysis about the
usage of MathML markup used in Apple's product. How can we proceed to
obtain it?

Thanks,

[1] https://www.w3.org/community/mathml4/
[2] https://github.com/mathml-refresh/mathml/issues/

On 15/03/2019 22:33, Myles C. Maxfield wrote:
>
>
>> On Mar 15, 2019, at 11:29 AM, Ryosuke Niwa > <mailto:rn...@webkit.org>> wrote:
>>
>>
>> On Fri, Mar 15, 2019 at 3:08 AM Frédéric Wang > <mailto:fw...@igalia.com>> wrote:
>>
>> Hello WebKit developers,
>>
>> As some of you may know, Igalia is working on MathML support in
>> Chromium
>> this year [1]. As part of that effort we joined a new MathML Refresh
>> Community Group [2] and one goal is to focus on a core spec for
>> browser
>> implementations [3] to:
>> - Remove deprecated/uncommon/duplicate math features that could be
>> implemented by polyfills (relying on MathML core and other web
>> technologies).
>>
>>
>> I'd be very much concerned about backwards compatibility here when it
>> come to removing any features.
>> It's important to notice that WebKit is also used by hundreds of
>> thousands of iOS apps and macOS apps.
>> How do we know we won't break those applications?
>>
>> In general, I don't agree with whatever Google said about MathML
>> being too complex, etc…
>
> The original sentence doesn’t say they will be removing anything in
> WebKit. There are plenty of features that have been removed from specs
> that we continue supporting in WebKit for backwards compatibility.
>
> We could also consider migrating our implementation to a JS polyfill
> if one exists.
>
> Is there a characterization of which features are planned for
> deprecation? We might be able to do some analysis on iBooks' and iOS
> apps’ content.
>
>>
>> - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
>> help implementation and conformance testing.
>> - Align MathML with CSS/HTML (parsing, layout...), introducing
>> new web
>> platform features (CSS, fonts...) for math if necessary.
>>
>
> This sounds wonderful! A more coherent MathML story going forward
> would be fantastic.
>
>>
>> On the other hand, these seem like very valuable improvements.
>>
>> We expect that this effort will improve browser interoperability and
>> reduce complexity of current implementations.
>>
>>
>> Given there aren't too many websites that deploy MathML directly on
>> production, my concerns are more about existing iOS and madOS apps
>> that embed WKWebView or WebView / UIWebView and use MathML.
>>
>> - R. Niwa
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>

-- 
Frédéric Wang

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


[webkit-dev] MathML Refresh Heads up

2019-03-15 Thread Frédéric Wang
Hello WebKit developers,

As some of you may know, Igalia is working on MathML support in Chromium
this year [1]. As part of that effort we joined a new MathML Refresh
Community Group [2] and one goal is to focus on a core spec for browser
implementations [3] to:
- Remove deprecated/uncommon/duplicate math features that could be
implemented by polyfills (relying on MathML core and other web
technologies).
- Add more detailed algorithms (based on TeX/OpenType/CSS layout) to
help implementation and conformance testing.
- Align MathML with CSS/HTML (parsing, layout...), introducing new web
platform features (CSS, fonts...) for math if necessary.

We expect that this effort will improve browser interoperability and
reduce complexity of current implementations.

This is just a heads up to say that we will send patches to
update/remove/add features. For people who are interested, we opened a
meta bug to track these changes [4].

Frédéric Wang and Rob Buis,

[1] https://mathml.igalia.com/
[2] https://mathml-refresh.github.io/
[3] https://mathml-refresh.github.io/mathml-core/
[4] https://bugs.webkit.org/show_bug.cgi?id=195797

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


[webkit-dev] Turning on/off web preferences during iOS development

2019-02-21 Thread Frédéric Wang
Hi everybody,

I was wondering if there is an easy way to enable or disable a web
preference on iOS (simulator). Some of them are in the "experimental
features" menu but (at least with the public SDK) it has not always
worked well during development [1]. Moreover, most of the preferences
are now "internal features".

For the mac port, one can use the Experimental/Internal features menu in
minibrowser. For other ports, one can just modify the default value in
WebPreferences.yaml and rebuild, but that's a bit against the idea of a
runtime setting.

Any idea?

Thanks,

Frédéric

[1] https://bugs.webkit.org/show_bug.cgi?id=182485

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


Re: [webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API

2018-11-14 Thread Frédéric Wang
Hi all,

The main implementation is now submitted for review at:
https://bugs.webkit.org/show_bug.cgi?id=188043

It has some issue with smooth scrolling via scrollIntoView on nested
scrollers but I don't plan to work on this until the main part is
merged. See https://bugs.webkit.org/show_bug.cgi?id=189907

On 20/09/2018 22:26, Frédéric Wang wrote:
> Hi all,
>
> This email is to announce that I have started to work on (programmatic)
> smooth scrolling in WebKit from the CSSOM View specification [1]. To use
> this effect, web developers can pass a behavior parameter (auto, smooth,
> or instant) to Element.scroll, Element.scrollTo, Element.scrollBy,
> Element.scrollIntoView, Window.scroll, Window.scrollTo or
> Window.scrollBy [2]. When behavior is auto, the instant/smooth
> characteristic is actually taken from the value of a new CSS
> scroll-behavior property [3]. This new feature will be protected by a
> compile flag (enabled by default) and a runtime flag (an experimental
> feature). If you are interested, you can follow advancement on Bugzilla [4].
>
> Incidentally (and since that was convenient to do it before) I also
> added some basic support for new ScrollIntoView options [5] [6] that
> allow to specify how you want the revealed element to be aligned with
> respect to its scrollable ancestors.
>
> Cheers,
>
>
> Frédéric
>
> [1] https://drafts.csswg.org/cssom-view
> [2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions
> [3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
> [4] https://bugs.webkit.org/show_bug.cgi?id=188043
> [5] https://bugs.webkit.org/show_bug.cgi?id=189258
> [6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Experimental and (new) Internal feature flags

2018-11-06 Thread Frédéric Wang
On 05/11/2018 09:28, Manuel Rego Casasnovas wrote:
> I'm not sure about DRT. It seems you need to modify
> https://trac.webkit.org/browser/trunk/Tools/DumpRenderTree/TestOptions.cpp#L102
> in order that these headers work there.
Thanks rego. Probably this file should assert or log error for unknown
options, so that people realize they need to implement the parsing. I
opened https://bugs.webkit.org/show_bug.cgi?id=191303

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Testing iOS/WK1?

2018-10-24 Thread Frédéric Wang
On 23/10/2018 17:44, Ali Juma wrote:
> Try passing the argument "-1":
>
> run-webkit-tests --ios-simulator -1

Great thanks for the hint, I think this --dump-render-tree could be
useful indeed to check WK1.

However, in the particular scrolling tests I'm considering, I'm relying
a lot on testRunner.runUIScript to execute basic gestures or emulate the
find UI and most of these APIs are not implemented (easily
implementable?) in Tools/DumpRenderTree/ios/UIScriptControllerIOS.mm

-- 
Frédéric Wang - frederic-wang.fr

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


[webkit-dev] Testing iOS/WK1?

2018-10-23 Thread Frédéric Wang
Hi all,

During the WebKit Contributors Meeting, Simon Fraser suggested that I
should verify some of the my patches using WK1. Hence I did some
experiments (again):

* When I run run-webkit-tests, whatever the value specified via
--platform, the selected expectation is always a "wk2" file and the code
executed is from WebKit (i.e. WK2 == non-legacy).

* I wrote a dummy iOS app using the deprecated UIWebView [1] and tried
to launch it with Tools/Scripts/run-webkit-app --ios-simulator
/path/to/WebKitLegacyApp.app ; that seems to be working (code from
WebKitLegacy is indeed executed). Also, page is loaded and properly
rendered at startup so I can somewhat test it. However, the app does not
reply to user interaction so it's difficult to do manual testing (not to
mention features like the Find UI are not available).

Also, I have not checked but IIRC the EWS bots actually only run iOS/WK2
tests, right?

Any idea/suggestion regarding how one could test iOS/WK1?

PS: I'm using the public Xcode SDK. In particular I only have access to
the simulator.

[1] https://github.com/fred-wang/WebKitLegacyApp

-- 
Frédéric Wang - frederic-wang.fr


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


Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc

2018-09-24 Thread Frédéric Wang
On 10/09/2018 10:41, Frédéric Wang wrote:
> The new behavior is enabled for tests after
> https://trac.webkit.org/changeset/235806/webkit
> Essentially, this means that if you want set/get the scroll position of
> the test pages, you should now just use document.scrollingElement
> instead of document.body.
>
> I'll wait a few days before proposing to set it to
> DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing :
> https://bugs.webkit.org/show_bug.cgi?id=189472
Given the new policy for experimental features and given that the
behavior has already been enabled for all tests for 2 weeks now, we
should either 1) remove the flag from the experimental category and
enable by default or 2) disable it for tests and enable it on a per-test
basis using headers.

I'm proposing the former in https://bugs.webkit.org/show_bug.cgi?id=189472

Note that enabling the flag is a big behavior change that might impact
users but at the same time will fix an old compatibility issue between
WebKit (non-standard behavior) VS Chromium/Gecko/Edge (CSSOMView behavior).

-- 
Frédéric Wang - frederic-wang.fr


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


Re: [webkit-dev] Experimental and (new) Internal feature flags

2018-09-24 Thread Frédéric Wang
On 12/09/2018 23:48, Dean Jackson wrote:
> What about testing?
> 
>
> You can turn both experimental and internal features on via headers in 
> WebKitTestRunner. Use experimental:FeatureName or internal:FeatureName. For 
> example...
>
> 
IIUC some platforms (WK1?) still use DumpRenderTree to run tests? Are
such headers taken into account on these platforms too?

-- 
Frédéric Wang - frederic-wang.fr

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


[webkit-dev] [CSSOM View] Smooth scroll behavior via CSS property / DOM scroll* API

2018-09-20 Thread Frédéric Wang
Hi all,

This email is to announce that I have started to work on (programmatic)
smooth scrolling in WebKit from the CSSOM View specification [1]. To use
this effect, web developers can pass a behavior parameter (auto, smooth,
or instant) to Element.scroll, Element.scrollTo, Element.scrollBy,
Element.scrollIntoView, Window.scroll, Window.scrollTo or
Window.scrollBy [2]. When behavior is auto, the instant/smooth
characteristic is actually taken from the value of a new CSS
scroll-behavior property [3]. This new feature will be protected by a
compile flag (enabled by default) and a runtime flag (an experimental
feature). If you are interested, you can follow advancement on Bugzilla [4].

Incidentally (and since that was convenient to do it before) I also
added some basic support for new ScrollIntoView options [5] [6] that
allow to specify how you want the revealed element to be aligned with
respect to its scrollable ancestors.

Cheers,


Frédéric

[1] https://drafts.csswg.org/cssom-view
[2] https://drafts.csswg.org/cssom-view/#dictdef-scrolloptions
[3] https://drafts.csswg.org/cssom-view/#propdef-scroll-behavior
[4] https://bugs.webkit.org/show_bug.cgi?id=188043
[5] https://bugs.webkit.org/show_bug.cgi?id=189258
[6] https://drafts.csswg.org/cssom-view/#dictdef-scrollintoviewoptions

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


Re: [webkit-dev] Unified sources have broken our #include hygiene

2018-09-13 Thread Frédéric Wang
Hi,

I've recently found two non-trivial issues with unified builds. They are
not missing #include but instead conflicts between C++ files:

- Two C++ files including the same header but with a #define directive
set to different values [1].
- One C++ file including a header with implicit template instantiation
in an inline function before an explicit template specialization in a
second C++ file. [2]

I guess there could be more examples like this (e.g. functions with
conflicting names in two C++ files...). Should we allow to prevent some
files to be included in unified build? This is possible in Mozilla's
build system for example [3].

Or should we always try to re-write the code to fix the conflicts
between files? This might go against our usual practice: For example the
current solution I have for [2] is to move the function from the header
to its implementation C++ file, losing potential performance benefit of
inlining...

[1] https://bugs.webkit.org/show_bug.cgi?id=189579
[2] https://bugs.webkit.org/show_bug.cgi?id=189541
[3] https://dxr.mozilla.org/mozilla-central/source/dom/canvas/moz.build#70

On 02/09/2018 02:14, Simon Fraser wrote:
> Unified sources allow you to get away without #including all the files you 
> need in a .cpp file, because some earlier file in the group has probably 
> already included them for you.
>
> This means that when you add a new file to the build, and the unified sources 
> get shuffled around, you end up with a long list of build breakages, some 
> platform-specific, that you can only fix by repeating EWS trials. Here's an 
> example: https://bugs.webkit.org/show_bug.cgi?id=189223. That patch added on 
> new file in Source/WebCore/rendering, which required unrelated #include 
> changes in at least:
>
> rendering/RenderBlockFlow.cpp:
> rendering/RenderFrame.cpp:
> rendering/RenderImage.cpp:
>
> How can we solve this? Should we have an EWS that builds non-unified? Can we 
> somehow have the style checker do #include enforcement?
>
> Simon
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Frédéric Wang - frederic-wang.fr


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


Re: [webkit-dev] Experimental and (new) Internal feature flags

2018-09-13 Thread Frédéric Wang
Thanks for the heads-up. Some random thoughts on this:

* For WPT tests, I would like a solution that does not discourage WebKit
developers to contribute new tests to upstream WPT. It seems to me that
such a risk exists for the proposal based on a header in the files.

* The per-directory or per-file configuration allows to verify the new
feature for a particular set of tests. However, enabling new feature
often affects other existing tests and may require further adjustments.
It is actually good to enable new features for tests as early as
possible since it sometimes helps WebKit developers to detect issues
they had not initially expected. Right now it happens when the feature
is set to DEFAULT_EXPERIMENTAL_FEATURES_ENABLED. IIUC with the current
proposal that will now only happen when the feature is removed from the
experimental category and hence already considered stable enough for
shipping.

* Similarly, I wonder what will be the behavior of experimental features
in Safari Tech Preview? I think currently they can be on by defaut and
hence allows to get early feedback from Web developers. Again they might
be affected by a new feature, even when they don't know about it at all
(and hence would not try to explicitly enable it). IIUC, with the
current proposal, they will always be off by default.

* A bit tangential, but I wonder whether we should have a policy to
handle web-facing changes. Mozilla and Chromium developers typically
send "Intent to implement/ship/remove etc" to their developer mailing
lists so that people are aware of the web-facing changes and can discuss
them. As previously mentioned, people might only notice a behavior
change once the new feature is enabled. IIUC, with the current proposal
that will again only happen once the feature is no longer considered
experimental.

-- 
Frédéric Wang - frederic-wang.fr


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


Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc

2018-09-10 Thread Frédéric Wang
Hi all,

The new behavior is enabled for tests after
https://trac.webkit.org/changeset/235806/webkit
Essentially, this means that if you want set/get the scroll position of
the test pages, you should now just use document.scrollingElement
instead of document.body.

I'll wait a few days before proposing to set it to
DEFAULT_EXPERIMENTAL_FEATURES_ENABLED and allow wider testing :
https://bugs.webkit.org/show_bug.cgi?id=189472

Frédéric

On 30/01/2018 17:21, Frédéric Wang wrote:
> Hi everybody,
>
> I'd like to announce that I started to implement the behavior for
> scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and
> scrollingElement [1] as specified by the CSSOM View specification [2].
>
> To summarize, the main difference is which element to use in order to
> set or get the scroll properties of the viewport in standard
> (non-Quirks) mode:
>
> * The CSSOM View spec says it should be document.documentElement and
> most browsers implement it that way.
> * Chromium used to use document.body but this has recently been changed
> to follow the CSSOM View spec [3].
> * WebKit still uses document.body and I'm proposing to change this behavior.
>
> Note that this is likely to break existing content. The change was
> attempted in WebKit in the past but broke some non-regression tests [4].
> Chromium people also had some issues when trying to ship the change but
> things went well at the end [5].
>
> For now I'm developing it under a CSSOMViewScrollingAPI developer flag.
> I was able to run the tests with that flag enabled, modulo a few test
> adjustments.
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=5991
> [2] https://drafts.csswg.org/cssom-view
> [3]
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4
> [4] https://bugs.webkit.org/show_bug.cgi?id=106133,
> https://bugs.webkit.org/show_bug.cgi?id=121876
> [5]
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ
> ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20
>

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Standard process for exporting new WPT tests?

2018-05-24 Thread Frédéric Wang
On 25/05/2018 00:52, Ryosuke Niwa wrote:
>
> Yes, it's okay for a WebKit commit to merge the change which got
> merged into WPT but it's never okay to first commit the test into
> WebKit and then later upstream it to WPT...
If that's what you meant by "NEVER commit new tests into
LayoutTests/imported/w3c/web-platform-tests" then I agree it's very
sensible. On the other hand, if someone uploads a patch adding a new
test to LayoutTests/imported/w3c/web-platform-tests without the
corresponding GitHub PR I would expect that we only cq- this patch and
point that person to a link explaining clearly the WPT export process
and agreement.

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Standard process for exporting new WPT tests?

2018-05-24 Thread Frédéric Wang
Thank you everybody for your replies. So summarizing:

* WebKit devs should be able to choose between:
  - submitting new WPT tests to the GitHub WPT repo first and then
importing them to the WebKit repo after they are approved.
  - OR submitting patches to WebKit Bugzilla first and then exporting
them to the GitHub WPT repo.

* In any case, you should never land a test into the WebKit repo before
the corresponding test has successfully landed into the GitHub WPT repo.

* We now have Tools/Scripts to import and export WPT tests. In
particular the latter script ensures that the previous condition is
satisfied.

I believe a wiki page to explain the process for adding WPT tests to
WebKit should be accessible from
https://trac.webkit.org/wiki#LayoutTests so that with have a centralized
documentation people can refer to.

Maybe this could be the following one but it was last updated three
years ago and does not mention the latest tools/agreements/work-in-progress:
https://trac.webkit.org/wiki/WebKitW3CTesting

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Standard process for exporting new WPT tests?

2018-05-23 Thread Frédéric Wang
On 23/05/2018 22:50, Ryosuke Niwa wrote:
> As we have preciously discussed, we should NEVER commit new tests into
> LayoutTests/imported/w3c/web-platform-tests.
>
I don't understand this comment. Can you please elaborate or indicate
where this was discussed?

We have used the import script exactly to import/update WPT tests into
LayoutTests/imported/w3c/web-platform-tests (and in particular add new
tests).

Also I understand Youenn's export script is supposed to allow committing
new tests to LayoutTests/imported/w3c/web-platform-tests and upstreaming
them to WPT.

-- 
Frédéric Wang - frederic-wang.fr


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


[webkit-dev] Standard process for exporting new WPT tests?

2018-05-23 Thread Frédéric Wang
Hi all,

When implementing new platform features in WebKit, some of us write new
WPT tests in order to verify spec conformance. One of the reason to use
this format is that the tests can then be easily shared with web engine
developers and people involved in standardization, an important feature
for web platform developers.

Youenn has shared various ideas to export such WPT tests to the W3C
GitHub repository in the past [1] [2] [3] but I'm not sure the WebKit
community has reached an agreement.

There are basically two ways to proceed:

1) Either submit WPT tests to GitHub (or Mozilla / Chromium) repository,
get them reviewed and do the import within the patch that implements the
feature in WebKit.

2) Or submit the patch with new WPT tests to WebKit, get it reviewed and
export it to GitHub (later sync with Mozilla / Chromium).

The first option has the advantage to get more people involved in test
review, which sometimes gives faster replies or useful advice from
people who more familiar with the spec. However, the second option has
the advantage of not splitting the coding & testing parts and is better
for the WebKit implementers and reviewers. That latter option also
aligns with what Mozilla and Chromium developers do.

Can we please agree on a way to proceed? And add documentation somewhere
for developers/reviewers?

Thanks!


[1] https://lists.webkit.org/pipermail/webkit-dev/2017-March/028884.html
[2] https://lists.webkit.org/pipermail/webkit-dev/2017-April/028932.html
[3] https://lists.webkit.org/pipermail/webkit-dev/2017-December/029837.html

-- 
Frédéric Wang - frederic-wang.fr


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


Re: [webkit-dev] Tips to build faster on Mac?

2018-03-28 Thread Frédéric Wang
On 27/03/2018 18:16, Dan Bernstein wrote:
>
>
>> On Mar 27, 2018, at 9:07 AM, Frédéric Wang <fw...@igalia.com
>> <mailto:fw...@igalia.com>> wrote:
>>
>> I see that the make command allows to make incremental builds for
>> macOS. Does anyone know how to specify that we want to build for the
>> iOS Simulator?
>
> Add SDKROOT=iphonesimulator to the make invocation.

That works, thanks!

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Tips to build faster on Mac?

2018-03-27 Thread Frédéric Wang
On 23/03/2018 23:08, Danyao Wang wrote:
> Thanks everyone! I had a chance to try plain "make d -C
> Source/WebCore" today and it's a lot faster. Small changes build under
> a minute, so this is very helpful!
>
> On Fri, Mar 16, 2018 at 12:40 PM, Maciej Stachowiak <m...@apple.com
> <mailto:m...@apple.com>> wrote:
>
>
> You can also just cd to the WebCore directory and type make.
>
>> On Mar 16, 2018, at 3:24 PM, youenn fablet <youe...@gmail.com
>> <mailto:youe...@gmail.com>> wrote:
>>
>> If you have a full build and made changes to WebCore, you might
>> only need to recompile WebCore. With make for instance, one can do:
>> make d -C Source/WebCore
>>
>>   Y
>>
>> On Fri, Mar 16, 2018 at 6:55 AM Danyao Wang <dan...@chromium.org
>> <mailto:dan...@chromium.org>> wrote:
>>
>> Thanks Brian for the Xcode UI tip! So far I've always used
>> build-webkit. I didn't realize there could be a difference.
>>
>> On Thu, Mar 15, 2018 at 6:01 PM, Brian Burg <bb...@apple.com
>> <mailto:bb...@apple.com>> wrote:
>>
>>
>>
>> > On Mar 15, 2018, at 1:58 PM, Danyao Wang
>> <dan...@chromium.org <mailto:dan...@chromium.org>> wrote:
>> >
>> > Hi,
>> >
>> > Being new to WebKit development (and also switching
>> from Linux to Mac), I find my workflow relatively clumsy.
>> Building on a fresh checkout usually takes me 20+ minutes
>> even on my 12-core Mac Pro. Fastest incremental builds
>> are ~2 minutes. This adds a lot to the develop / test /
>> debug cycle.
>>
>> These build times seem normal. WebKit is a big project,
>> and we don’t use CMake/ninja by default when building for
>> Cocoa ports.
>>
>> Are you building via build-webkit on the command line? In
>> my experience, incremental builds are faster via Xcode’s UI.
>>
>> > I heard the good folks from Igalia working on the GTK
>> port use icecc. Has anyone used this on Mac? Any other
>> productivity tips?
>> >
>> > Thanks!
>> > Danyao
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> <mailto:webkit-dev@lists.webkit.org>
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

Hi all,

I see that the make command allows to make incremental builds for macOS.
Does anyone know how to specify that we want to build for the iOS Simulator?

Thanks!

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc

2018-02-07 Thread Frédéric Wang
On 30/01/2018 17:21, Frédéric Wang wrote:
> Chromium people also had some issues when trying to ship the change but
> things went well at the end [5].
>
> [5]
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ
> ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20

I am told by Chromium developers that the workaround they had to
introduce for smoothscroll.js won't be necessary for WebKit, because we
don't have "chrome" in the UA string. Of course that does not mean that
the behavior changes won't cause any other issue...

-- 
Frédéric Wang - frederic-wang.fr

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


[webkit-dev] CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc

2018-01-30 Thread Frédéric Wang
Hi everybody,

I'd like to announce that I started to implement the behavior for
scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and
scrollingElement [1] as specified by the CSSOM View specification [2].

To summarize, the main difference is which element to use in order to
set or get the scroll properties of the viewport in standard
(non-Quirks) mode:

* The CSSOM View spec says it should be document.documentElement and
most browsers implement it that way.
* Chromium used to use document.body but this has recently been changed
to follow the CSSOM View spec [3].
* WebKit still uses document.body and I'm proposing to change this behavior.

Note that this is likely to break existing content. The change was
attempted in WebKit in the past but broke some non-regression tests [4].
Chromium people also had some issues when trying to ship the change but
things went well at the end [5].

For now I'm developing it under a CSSOMViewScrollingAPI developer flag.
I was able to run the tests with that flag enabled, modulo a few test
adjustments.

[1] https://bugs.webkit.org/show_bug.cgi?id=5991
[2] https://drafts.csswg.org/cssom-view
[3]
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4
[4] https://bugs.webkit.org/show_bug.cgi?id=106133,
https://bugs.webkit.org/show_bug.cgi?id=121876
[5]
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/GO7qLkg4BwAJ
; https://bugs.webkit.org/show_bug.cgi?id=5991#c20

-- 
Frédéric Wang - frederic-wang.fr

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


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-28 Thread Frédéric WANG
On 28/11/2017 16:24, Philip Jägenstedt wrote:
>
> To do the upstreaming from WebKit first would get around this problem,
> and is something I could see us doing. If a Chromium developer
> upstreamed tests from WebKit and got review from a WebKit reviewer, I
> think we would rubberstamp the corresponding removal in Chromium.
>
> But that would be a futile exercise if the WebKit reviewers don't want
> to delete the tests from WebKit. The only remaining options would then
> be not sharing the tests with EdgeHTML and Gecko, or creating more
> duplication for WebKit.
Note that we can also have duplication in WebKit but for each port
decide which version will be executed by adding "skip" tags in
TestExpectation. Not ideal in my opinion, but that would allow e.g.
GTK/WPE ports to run the latest WPT tests while macOS/iOS ports keep the
legacy LayoutTests/ versions / history.

-- 
Frédéric Wang - frederic-wang.fr



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-24 Thread Frédéric WANG
On 17/11/2017 17:23, Maciej Stachowiak wrote:
> I should also note that pulling in the test suite won't automatically
> get the bugs fixed or prioritized, or even filed in the bug tracker
> necessarily.eratwerATWeRTWAerATWertwAerer 
Sure. However, I believe in general having more people importing the WPT
tests and trying to match the behavior of the spec and of other browsers
would help, if only to be aware of issues (as Philip mentioned we could
also improve notifications etc). In the particular cases I mentioned
https://bugs.webkit.org/show_bug.cgi?id=162668 was reported one year ago
after Khaled Hosny (invited expert for the WebFonts WG) fixed the bug in
the GTK port while https://bugs.webkit.org/show_bug.cgi?id=179237 just
requires to backport the changes in Chromium to match the latest WebVTT
spec. These are of course only two examples, but in general more tests
shared with the rest of the Web Platform community (developers and spec
authors) are very useful for improving WebKit and interoperability.
> I find it super convenient that EWS runs all the tests even on WIP
> patches. It often catches test failures in tests I didn't think to run
> myself. I think it would be great if EWS could run tests on more
> platforms. Just running release regression tests on more platforms
> would be a big win, if debug builds are the gating factor. I guess it
> would be kind of neat to have a feature of "run the tests across all
> configurations, but only some of them". But I don't think I would
> prioritize it over having more kinds of tests, or finding ways to make
> the full test suite run faster.
Right, running all the tests is nice. But sometimes I personally feel
guilty to have to execute everything on EWS for example to retrieve
results for macOS/iOS (when I did not have access to a mac) or to fix
compilation failures on Windows ports. So better granularity would be
helpful in my opinion. In any cases, this was just one idea and people
working on CI and infrastructure are in better position to know how to
improve running time of WPT tests. I'm surprised that I don't hear such
complaints from Mozilla and Chromium (but maybe I'm not aware of them).

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-17 Thread Frédéric WANG
On 17/11/2017 16:26, Maciej Stachowiak wrote:
> WebKit has a lot of tests that were regression tests for a specific
> bug fix, not as conformance tests (though they might b useful for that
> too). In such cases, the association with the bugs.webkit.org bug is
> more important than the spec URL. That’s particularly the case when
> the test has been changed multiple times to reflect further WebKit
> behavior changes. I know that I’ve personally found it very useful to
> look at revision history of tests, or search for bug numbers or
> keywords in LayoutTests/ChangeLog to find related tests.
> Not saying this is the sole purpose of tests, but losing this ability or 
> making it more awkward would be a downside to deleting tests from the WebKit 
> repo.
Well, I think we agree here, that's why "conformance" tests was
specified in my message. For such tests, connecting the history of tests
with the development of the specs is actually more important. For
example I recently noticed that some bugs with WOFF2 (on Apple's ports
only) and WebVTT have been ignored in WebKit because we don't
import/sync WPT tests for these specs.
> Maybe I’m missing something, but isn’t that already how it works in WebKit? 
> EWS and buildbot run all the tests, but on your own machine you can get 
> run-webkit-tests to run any subset you want.
Not everybody has the hardware to produce debug builds of WebKit on all
existing ports and run a big amount of tests :-)

AFAIK, EWS run all the builds as well as all the tests on macOS/iOS, you
don't have options to select a subset of the tests or the ports.
Buildbots run all the builds & tests on all platforms *after* a patch
lands in the main repo. So we do too much for WIP patches (extra runtime
cost I'm mentioning here) and not enough to check the final patch before
landing (which causes different issues like extra rollout or gardening
commits or difficult regression bisecting).

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

2017-11-17 Thread Frédéric WANG
Hi Philip,

We (at Igalia) are strong supporters of WPT tests and we've appreciated
a lot the effort made by Youenn and others to make them possible in
WebKit. They are very important for interoperability and make life much
easier for developers working on different WebKit ports and different
Web engines.

Ideally, we believe that future conformance tests in WebKit should be
written using the WPT format and submitted to web-platform-tests
repository (of course there are exceptions when the WPT API is too
limited). WPT tests have references to spec URLs and their own git
history, so it should always be possible to know why they have been
written. This also reduces review cost on WebKit's side, as test review
can be done by experts in the relevant specs.

Probably it would be nice to convert old tests to WPT and check
duplication to avoid increasing runtime cost but that's indeed going to
be a big effort. It could also be possible to improve how the CI tests
are executed in the WebKit project, taking inspiration from Chromium or
Mozilla projects (i.e. run all tests before a patch lands in the main
repo, but allowing devs to run a relevant subset during development).

In any case, Igalia definitely supports this proposal and is happy to
help where possible.

Frédéric, for Igalia's Web Platform Team


signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Frédéric WANG
On 25/10/2017 19:05, Maciej Stachowiak wrote:
>
> (1) Is it at all common to use MathML with a math font specified as a web 
> font? Can you give an example?
I can't say whether it is "common" but I guess the trick is well known
by MathML users, since unfortunately many systems do not provide math
fonts by default. I have a github repo with known fonts at
https://github.com/fred-wang/MathFonts

As an example Jacques Distler uses STIX 2 WOFF on his blog:

https://golem.ph.utexas.edu/~distler/blog/archives/002702.html
https://golem.ph.utexas.edu/~distler/blog/styles-site.css

Some people also bundle WOFF fonts in web apps or ebooks. Web fonts are
also used by browser addons e.g.
https://addons.mozilla.org/en-US/firefox/addon/mathml-fonts/ which allow
to workaround the lack of system fonts (and the impossibility to install
them for users).

Website using MathML often have a page with installation instructions
for math fonts, for example on NIST dlmf:
http://dlmf.nist.gov/help/mathml#S3

Note that I've seen similar things (WOFF fonts, addons, instructions)
for other languages in the past e.g.
https://addons.mozilla.org/en-US/firefox/addon/khmer-fonts-package/, so
again it's not specific to math.

> (2) Is it at all common to use MathML only to the extent that it's rendered 
> fine without a math font?
Again, I'm not sure how common it is but I've seen some users happy with
basic MathML rendering for elementary calculations. I was also surprised
to see some people excited about my CSS stylesheet at
https://github.com/fred-wang/mathml.css that can render very basic math.
There are a lot of such formulas on Wikipedia, for sure for instance
https://en.wikipedia.org/wiki/Fraction_(mathematics) contains MathML
formulas that can be rendered without specialized math fonts.
> (3) In the cases above, is there usually an image fallback?
It really depends on the website. But definitely people using MathML
need some fallback (image, CSS layout, javascript layout, text etc).

How this fallback is triggered depends on the website, there is not any
real rule. IIUC, the argument mentioned earlier only considers the case
where an author would try to detect MathML support and automatically
fallback to an image otherwise. As I said, authors could also try to
detect availability of math fonts, or provide WOFF fallback (Distler's
blog), or have a page to explain how to install fonts (e.g. NIST dlmf),
or use image by default and explain how to enable MathML & install fonts
(e.g. Wikipedia), or provide LaTeX fallback in an  (my blog)
or...

IMHO, platform owners should not speculate on what authors will do.
Disabling MathML just because of the lack of math fonts, does not seem a
good idea. On the one hand, if MathML is enabled page authors can still
decide to serve fallback content if they think the support is not good
enough on the user platform. On the other hand, if the platform owner
has disabled MathML, then there is no way for users/authors willing to
use MathML to force it to be enabled again...
> Why don't we wait to hear from port owners whether they would actually want 
> to disable MathML for reason of compatibiltiy. Knowing answers to the above 
> questions would help.
Sure. My email was to follow-up on
https://bugs.webkit.org/show_bug.cgi?id=177744 and the discussions at
the Web Engines Hackfest, so they are not forgotten. But there is no
hurry to remove the build flag for now.

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-25 Thread Frédéric WANG
On 24/10/2017 18:50, Maciej Stachowiak wrote:
> I don't have a strong opinion on whether we should support disabling
> MathML. My point is just that if we support disabling it, it should be
> a runtime switch, not compile-time.
> Good reasons to have a compile-time switch would be:
> - Some ports want the code size savings
> - It requires back-end code that is not available on all ports
>
> But neither of those is true.
>
> On the other hand, we might still want a runtime switch if some ports would 
> like to disable the feature for reason of compatibility based on available 
> fonts. I think it's up to port owners to say whether they want to disable the 
> feature for this reason.
Hi,

I believe it is up to the platform owners to decide whether they want to
provide math fonts by default ; depending on whether they want to
privilege disk space or a better user experience.

However, I still don't see the connection between available fonts and
enabling MathML support. As I said, some pages with MathML provide the
necessary WOFF math fonts while others just use basic math (fractions
etc) where the default text fonts are enough. So the owners would be
intentionally breaking these pages, just because they don't provide math
fonts on their platforms ? That sounds weird, to me.

Also I think a runtime flag makes sense for the use case of the Tor
project, but it is a separate use case IMHO and it should not be
blocking the removal of the compile-time flag.

So to summarize, I'm happy to submit a patch to remove ENABLE(MATHML) if
the only reasons were the two points you mention (which as you said are
not true here). However, if some port owners provide a concrete
explanation of why they want to keep the option of disabling MathML then
I don't think I'll have time to check the runtime option right now, so
I'll just keep the status quo and it will be up to these people to
submit a patch or to keep fixing the build failures for --no-mathml ;-)

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-24 Thread Frédéric WANG
On 24/10/2017 11:35, Olivier Blin wrote:
> Hi,
>
> The difference is about 250 kB on libWPEWebKit.so.0 for a WPE build on
> my ARMv7 target:
>
> - without MathML : 37474160
> - with MathML: 37726056
>
> This can still be significant on low-end devices, with 128 MB of flash
> storage.
>
Thank you Olivier. That indeed seems to match Adrián's guess of "a few
hundreds of kilobytes".

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-24 Thread Frédéric WANG
On 24/10/2017 09:14, Frédéric WANG wrote:
> so it's a different use case and that one does not make sense to me.
*does make sense*

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-24 Thread Frédéric WANG
On 23/10/2017 18:25, Adrian Perez de Castro wrote:
> From your description it sounds that what takes more disk space in MathML are
> the needed math fonts, and that the amount of code added to WebKit when built
> is in the order of hundreds of kilobytes, at most (BTW, do you have figures of
> MathML enabld vs. disabled to confirm?). That being the case, it seems fine to
> me that MathML support is always enabled.
>
> Usually my main concern with removing compilation guards is forcing additional
> usage of megabytes of disk and/or memory in embedded platforms (which is, for
> example, the case for ENABLE_VIDEO: for the GTK+ and WPE ports it completely
> avoids the GStreamer dependency, which saves tens of megabytes!). But keeping
> the guards to save just a few hundreds of kilobytes is certainly not worth it,
> and in this case embedders can choose to not ship the math fonts.
>
> TL;DR: Fine by me, as it seems the compile flag only saves a few kilobytes in
> the built binaries, and the math fonts can't be skipped anyway by embedders.
>
> Best regards,
>
>
> --
>  Adrián 

Thanks Adrián. No, I wanted to do it during the Web Engines Hackfest but
did not have time to try. Also, Olivier mentioned he would check the
difference and tell whether it is significant or not for his project,
but I have not heard back from him yet.

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-24 Thread Frédéric WANG
On 23/10/2017 18:11, Maciej Stachowiak wrote:
>
> Is there any way we can convert MathML to a runtime switch? It seems
> like the main consideration is rendering quality given available
> fonts, rather than code size.
>
> Regards,
> Maciej
>
@Maciej:

As I explained, I don't think disabling a HTML5 feature to determine
which kind of fallback content will be delivered to the user is a good
idea. Authors can provide Web fonts and for very elementary math (e.g.
using only simple fractions) you even do not need math fonts at all.

Anyway, replying to your question the Tor project also added run-time
preferences for MathML and SVG in Gecko last year:

https://hg.mozilla.org/mozilla-central/rev/0d48c28cc547
https://hg.mozilla.org/mozilla-central/rev/7b09464eb767

IIRC, they basically move the MathML/SVG elements in "unknown"
namespaces so that the MathML/SVG content and layout classes are not
used to process them. I believe we could do the same for WebKit. Note
that their justification is security (users intentionally disable HTML5
features to "reduce attack surface area") so it's a different use case
and that one does not make sense to me.

In any cases, I do not think adding an runtime option for MathML/SVG is
a prerequisite to remove the build-time option, as the latter was more
about reducing binary size/dependencies for web engines developers while
the former was about providing more control to users.

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-24 Thread Frédéric WANG
@Konstantin I think you are a bit deviating from the main question but
FWIW: a) MathML also remains readable without math fonts as long as you
don't use complex content (same is true for normal text as long as you
do not use the rarest unicode characters) b) None of the feature
detection technique is perfect (mspace only tests a very basic MathML
feature, one can also make a test for available math fonts if present,
what if javascript is disabled? etc) and adding a build-time flag to
disable a HTML5 feature seems a very fragile way to guarantee the
content delivered to users.

SVG and MathML are features that share a common history (designed as
elements in a different namespaces, separate spec embedded in HTML5,
initially implemented under a build-time flags in Gecko and WebKit...)
so my point was really just that from the implementer point of view it
makes sense to handle them consistently, nothing more.

It seems you did not reply to the question about whether you have a
concrete use case of an embedded device where degrading HTML5 support to
help feature detection is important. I suspect for such device like
set-top box kind where math rendering is not essential, it does not
really matter whether MathML is enabled or not or whether fonts or
installed or not. But in any case, I still don't see why a build-time
flag would help and, as Maciej mentioned; it could better be a runtime
flag instead.

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-23 Thread Frédéric WANG
On 23/10/2017 18:04, Konstantin Tokarev wrote:
> There is a big difference between SVG and MathML: the first one is entirely 
> self-
> contained, while (AFAIU) MathML requires presence of math fonts on the target
> system for correct rendering (i.e. native MathML will look much worse than 
> image
> fallback that is usually available).
>
> Imagine embedded system (e.g. of set-top box kind) which has no math fonts on
> the board. Will always-on MathML be progression or regression there?
SVG also requires fonts for the  tag. And Web fonts exist to work
around the lack of system fonts. As a Web Platform developer, I believe
browser sniffing is bad practice, so I hope people use other techniques
to provide alternate content. Do you have any concrete use case in mind?

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal: Remove ENABLE(MATHML)

2017-10-23 Thread Frédéric WANG
Hi,

There have been some discussions recently on
https://bugs.webkit.org/show_bug.cgi?id=177744 regarding the relevance
of the compile-time flag for MathML. Discussing with Olivier during the
Web Engines Hackfest, it seems he only had disabled MathML in his
project because he thought it would reduce binary size. However, he was
not really sure this actually had a significant impact. AFAIK, the only
dependencies needed for MathML are the font libraries but they are
already used for text layout. The implementation is only a few
element/rendering files plus some changes here and there.

I'm wondering if other people use the --no-mathml build option and
believe they really need it? If not, I'm propose to remove this
compile-time flag.

As a comparison, the flag for SVG was removed in
https://bugs.webkit.org/show_bug.cgi?id=127991 ; Mozilla also removed
compile time option for MathML and SVG a long time ago (
https://hg.mozilla.org/mozilla-central/rev/b8664f450508 for the former).

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running Safari on the simulator

2017-10-13 Thread Frédéric WANG
Hello,

Just for the record, this is now fixed in
https://trac.webkit.org/changeset/223234

-- 
Frédéric Wang - frederic-wang.fr




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running Safari on the simulator

2017-09-28 Thread Frédéric WANG
On 28/09/2017 04:57, Daniel Bates wrote:
> Please file a bug.
>
> Dan
Done: https://bugs.webkit.org/show_bug.cgi?id=177595

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Running Safari on the simulator

2017-09-27 Thread Frédéric WANG
On 27/09/2017 19:24, Alex Christensen wrote:
> When I want to use the public iOS SDK for WebKit on iOS, I refer to
> Dan’s blog post
> at https://webkit.org/blog/3457/building-webkit-for-ios-simulator/
> We have bots using this configuration and they’re working successfully
> at https://build.webkit.org/waterfall?category=iOS
> Maybe you forgot to run configure-xcode-for-ios-development
>
I did run configure-xcode-for-ios-development indeed (otherwise the
build fails IIRC).
Also I forgot to say that I can use run-webkit-tests --ios-simulator
(which I guess is what is used on bots). My problem is with run-safari
--ios-simulator, which has stopped working recently.

Thanks,

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Running Safari on the simulator

2017-09-27 Thread Frédéric WANG
Hello,

I've recently upgraded XCode and rebuilt Safari but when I try running
Safari on the simulator, I get the following errors:

    Tools/Scripts/build-safari --ios-simulator --debug
    Tools/Scripts/run-safari --ios-simulator
    Quitting and launching iOS Simulator...
    Installing
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.0.sdk/Applications/MobileSafari.app.
    An error was encountered processing the command
(domain=NSPOSIXErrorDomain, code=2):
    Failed to install the requested application
    An application bundle was not found at the provided path.
    Provide a valid path to the desired application bundle.
    Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.

I can not find any MobileSafari.app in my WebKitBuild directory nor in
the /Applications/ directory calculated by webkitdirs.pm ; trying to
hardcode a different path in webkitdirs.pm I instead obtain:

    Quitting and launching iOS Simulator...
    Installing
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/Applications/MobileSafari.app.
    An error was encountered processing the command
(domain=IXUserPresentableErrorDomain, code=2):
    This app was unable to be installed.
    Died at /Users/fred/WebKit/Tools/Scripts/webkitdirs.pm line 2546.

Did anyone experience the same issue?

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Building WebKit for an iOS device

2017-07-12 Thread Frédéric WANG
Le 12/07/2017 à 19:19, Alex Christensen a écrit :
> WebKit can be built and run on the iOS simulator by anyone with the
> public iOS SDK.  I
> use https://webkit.org/blog/3457/building-webkit-for-ios-simulator/ when
> I forget how to do this.
>
> I guess WebKit can be built for device, but I’m pretty sure WebKit
> cannot be put as the system framework on an iOS device without
> Apple-internal tools.  With a lot of work you might be able to
> statically link everything into a custom app for local debugging, but
> I’m pretty sure such an app would be rejected by the App Store based
> on section 2.5.6
> of https://developer.apple.com/app-store/review/guidelines/
>
Yes, I'm already using the simulator for running tests and testing local
ios builds. I was just wondering whether it was possible to produce and
install a local build for development and testing purpose on a device.
Apparently from your reply and Michael's this seems quite unlikely with
the public iOS SDK :-( I guess it would be nice to mention this
limitation on https://webkit.org/building-webkit/

Thanks.

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Building WebKit for an iOS device

2017-07-12 Thread Frédéric WANG
Hello,

For development and testing purpose, I was wondering if there is a way
to produce a build of WebKit/Safari-mobile and to install it on a device
(instead of using the iOS simulator)? And is there any specific
requirement like having an Apple developer license and a registered device?

I know that we have a builder [1] and I just noticed the "--ios-device"
parameter for the build-webkit script but I can't find any information
on the official documentation [2] or on the WebKit wiki. I also tried
searching this mailing list about the topic but could not find any
relevant thread.

Thanks,

Frédéric

[1] https://build.webkit.org/builders/Apple%20iOS%2010%20Release%20(Build)
[2] https://webkit.org/building-webkit/




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Review of patch to support iframe's allow-popups-to-escape-sandbox?

2017-05-24 Thread Frédéric WANG
Hello,

Last month I uploaded a patch to support the
allow-popups-to-escape-sandbox flag for iframe's sandbox attribute [1].
As suggested by its name, it allows popups to escape sandboxing. I tried
to cc' people or find a reviewer on irc, but was not really successful
so far :-( Can anyone please take a look?

It seems that a bug with security involvement was fixed last year:
Basically popus were never sandboxed [2]. I see that the
allow-popups-to-escape-sandbox flag changes that behavior when it is
explicitly requested by the page's author, so I guess some careful
review (from Apple?) might be required here.

Thank you,

Frédéric

[1] https://bugs.webkit.org/show_bug.cgi?id=158875
[2] https://trac.webkit.org/changeset/204266


-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Recommended MathML fonts on WebKit platforms

2017-01-06 Thread Frédéric WANG
Le 13/03/2016 à 20:57, Darin Adler a écrit :
> 1) To make MathML work really well, platforms need to include appropriate 
> fonts. As you said, this is not a WebKit decision, but a decision made by 
> platform owners. If we want to advise them about the importance of this, it 
> would be good to draft something explaining how we, the WebKit project, see 
> this requirement and give advice on what to do. Someone should write a draft 
> of this recommendation so we can put it somewhere on webkit.org, and also so 
> we can discuss and make sure we agree on this advice. I’d like to see this 
> written in the form of a recommendation so we can see if this is really a 
> practical request. To give one example, “please use STIX Math, but version 2 
> which is not out yet” isn’t a great recommendation.
Hi all,

Last year, I had written some description of math fonts for MathML
rendering [1]. I'm resurrecting this discussion since "STIX Two" was
released last December with a complete redesign of the text portion [2].
"STIX Two Math" is now usable by WebKit for MathML rendering and is
included in the default stylesheet after [3].

Among available options, "STIX Two Math" provides the best coverage for
unicode characters and stretchy math operators. Also, some users prefer
it over the more traditional Computer Modern style of LaTeX systems [4].
I believe it would greatly improve user experience if STIX Two was
pre-installed on WebKit platforms. And as discussed in the original
thread, this would also help for MathML testing on mac.

(FYI, there are some bug entries to upgrade the STIX package of Linux
distributions. I also just updated my macOS Sierra to 10.12.2 but the
bundled STIX fonts are still from the obsolete & deprecated STIXGeneral
set...)

[1] https://trac.webkit.org/wiki/MathML/Fonts
[2] http://www.stixfonts.org/
[3] https://bugs.webkit.org/show_bug.cgi?id=165676
[4] https://golem.ph.utexas.edu/~distler/blog/archives/002926.html#more

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] ./Tools/Scripts/run-safari doesn't work with Safari 10

2016-07-18 Thread Frédéric WANG
Hi Marco,

You might want to check
https://trac.webkit.org/wiki/WebKitNightlyElCapWorkaround

In particular "If you want to use run a custom build, instead of using
run-safari (as usual), you'll need to set DYLD_FRAMEWORK_PATH and run
SafariForWebKitDevelopment manually. "

Hope that helps,

Frédéric

Le 18/07/2016 à 22:02, Marco Barisione a écrit :
> Hello,
>
> I recently installed Safari 10 on some machines running 10.11.6 DP. 
> Unfortunately, I cannot get Safari 10 to work with WebKit compiled from SVN.
>
> I tried with both SVN trunk (from today) and the revision tagged in SVN that 
> corresponds to my currently installed Safari (602.1.38.4).
> I compiled Safari with the usual:
>
>   $ ./Tools/Scripts/build-webkit
>
> And then I tried to run Safari with:
>
>   $ ./Tools/Scripts/run-safari
>
> Safari 10 starts, but nothing loads probably because it cannot load its 
> injected bundle. This is the output:
>
> Starting SafariForWebKitDevelopment with DYLD_FRAMEWORK_PATH set to point to 
> built WebKit in /Users/bari/src/webkit/WebKitBuild/Release.
> 2016-07-18 14:18:32.900 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:32.923 SafariForWebKitDevelopment[424:4918] [Keychain] 
> SecItemCopyMatching failed fetching extension list with error -34018
> 2016-07-18 14:18:33.091 com.apple.WebKit.WebContent.Development[425:4983] 
> Error loading 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari:  
> dlopen(/System/Library/StagedFrameworks/Safari/Safari.framework/Safari, 265): 
> Symbol not found: _OBJC_CLASS_$_WBSCompletionListRankingObserver
>   Referenced from: 
> /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
>   Expected in: 
> /System/Library/PrivateFrameworks/SafariShared.framework/Versions/A/SafariShared
>  in /System/Library/StagedFrameworks/Safari/Safari.framework/Safari
> InjectedBundle::load failed - Could not load the executable from the bundle.
>
>
> I’m a bit surprised that I couldn’t find anything about this problem in 
> bugzilla, IRC or on this mailing list.
> Am I doing something wrong or is this a problem with newer Safari? Is there 
> any fix/workaround for this?
>
> Thank you!
>




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: Use #pragma once instead of header guards

2016-07-14 Thread Frédéric WANG
FYI, I just performed that change as part of a general cleanup of MathML
headers:

https://trac.webkit.org/changeset/203228

The code style guidelines still mention the old-style header guards so
it should probably be updated:

https://webkit.org/code-style-guidelines/#names-header-guards

Le 10/03/2016 à 02:27, Anders Carlsson a écrit :
> Hi floks,
>
> Currently we use 
>
> #ifndef Header_h
> #define Header_h
>
> … 
>
> #endif
>
> I propose that we instead start using
>
> #pragma once
>
> which does the same thing. It can be faster on some compilers, is less error 
> prone and is one line instead of three! All compilers we use support #pragma 
> once.
>
> Thoughts?
> - Anders
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] MathML refactoring: Project Complete!

2016-07-13 Thread Frédéric WANG
Hi WebKit developers,

We are happy to announce that we are done with the MathML refactoring
proposed last December [1]. The first phase was a big clean up of the
MathML implementation and you can find details in a first blog post [2]
but essentially:

* MathML renderer classes now derive from RenderBlock instead of
RenderFlexible (except RenderMathMLTable which still derives from
RenderTable) so we no longer interfere with the flexbox code.
* MathML renderer classes do not create anonymous renderers any more
(except RenderMathMLFenced which creates anonymous
RenderMathMLOperators) so the render tree essentially matches the DOM tree.
* MathML renderer classes now perform simple box layout (again except
for RenderMathMLTable and RenderMathMLFenced) and should be much more
consistent with the rest of the WebKit code.

Many MathML rendering bugs have been fixed as an immediate consequence
of this clean up. But it also became much easier to follow OpenType MATH
& TeX rules for layout [3] and to implement important MathML features.
This has been done in a second phase and you can find details on the
MathML improvements in a second blog post [4].

During the development, we also decided to include a third phase: Moving
the parsing of MathML attributes into the DOM classes instead of doing
it in the renderer classes. This has only been partially achieved but
could be addressed in future developments. For those who are interested,
it is tracked in [5].

Finally, we tested the rendering on GTK, EFL, OS X and iOS ports and it
seems good. The status of the Windows port is unknown. We expanded the
test suite with more MathML tests and performed some gardening:
* All the tests pass on the GTK bots.
* All but the mismatch tests pass on EFL bots (it's not clear whether
screenshots are correctly taken).
* As discussed in a previous thread, OS X and iOS bots lack
pre-installed math fonts [6] and these fonts are not whitelisted by the
test runner. Most of the failures were due to tests requiring such math
fonts and so these tests are now skipped.
* The Windows port also has several unexplained failures but someone
should analyze that more carefully.

We plan to continue MathML developments in the future including
finishing some refactoring (RenderMathMLTable, attribute parsing...) and
improving MathML support and rendering quality.

Thank you again to all the people who made this contribution possible!

Frédéric, for the Igalia's Web Platform Team

[1] https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
[2] http://frederic-wang.fr/mathml-refactoring-in-webkit.html
[3] http://www.mathml-association.org/MathMLinHTML5/
[4] http://frederic-wang.fr/mathml-improvements-in-webkit.html
[5] https://webkit.org/b/156536
[6] https://trac.webkit.org/wiki/MathML/Fonts




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Status of the MathML layout refactoring

2016-06-27 Thread Frédéric WANG
Le 14/12/2015 à 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the 
> proposal sounds good and I am looking forward to the patches. 
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox, 
> but it still needs some of the flexbox functionality, the following pattern 
> has been introduced to the generic renderbox/block code. 
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Hi Zalan,

The final patch to move away from flexbox is now ready for review:

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

A patch based on Alex's initial attempt is still available and as you
can see we don't need to duplicate all of these RenderFlexibleBox
functions any more. We still need some minor adjustments to make
RenderMathMLBlock inherits from RenderBlock, though. In particular,
regarding the 4 changes in RenderBox you mentioned we actually still
need to keep two of them because MathML renderers shrink to fit their
content instead of occupying the width of their container.

Regards,

Frédéric



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Status of the MathML layout refactoring

2016-06-15 Thread Frédéric WANG
Hi all,

Last December, Alex wrote an announcement about some refactoring of the
MathML layout code [1]. We slightly deviated from the plan proposed
there: the two separate steps (Remove FlexBox dependency without
changing the RenderTree structure and then Refactor the RenderTree
structure) are now expected to be done in a single phase. We also added
more phases: Adding support for important MathML features and OpenType
MATH properties ; and ​Moving all parsing of MathML attributes from
renderer classes to element classes.

You can get a detailed explanations and status on the trac wiki [2]. As
you can see we have already merged many patches of phase 1 and we are
close to make MathML independent from flexbox. We would definitely
welcome any help to complete that work as soon as possible... So if some
of you have time to review these patches or at least provide feedback,
that would be much appreciated!

Note that this refactoring mainly focuses on code quality so that it is
easier to maintain and to add future improvements. However, if you are
curious about how mathematical formulas will look like after the
refactoring, see [3] for a screenshot of Mozilla's MathML torture test
[4] in Safari, using the Latin Modern Math font [5].

Thanks,

Frédéric Wang

[1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
[2] http://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
[3]
http://people.igalia.com/fwang/images/mac-webkitrefactored-latinmodernmath.png
[4]
https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/MathML_Torture_Test
[5] The importance of fonts for math rendering has already been
discussed in a previous thread. See
http://trac.webkit.org/wiki/MathML/Fonts for the latest update.




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVG images with foreignObject inside canvas

2016-04-05 Thread Frédéric WANG
Le 04/04/2016 22:22, Philip Rogers a écrit :
> Hi Frédéric,
>
> I'm sorry you had to hit this confusing area recently. I just filed
> https://bugs.webkit.org/show_bug.cgi?id=156176 which we can use to
> track progress on this.
>
> The core issue is that foreignObject has the potential to leak
> information (e.g., visited links), and there hasn't been enough user
> interest to justify removing that restriction.
Hi Philip,

Thank you very much for opening the bug!

Yes, I'm aware of this security issue... I did not follow the details
when that happened, but Mozilla has implemented support for
foreignObject inside canvas for several years and there is an article on
MDN describing it:

https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Drawing_DOM_objects_into_a_canvas

Maybe it would be worth checking with them what was their rationale to
remove that restriction and if it's worth following the same approach
for Blink/WebKit...

Frédéric



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] SVG images with foreignObject inside canvas

2016-04-01 Thread Frédéric WANG
Hi,

After bug 119492, SVG images are allowed inside canvas without tainting
as long as they do not contain foreignObject. Two months ago, changeset
195614 landed to make this a bit more secure and the following FIXME
comment was added to SVGImage.cpp:

// FIXME: Once foreignObject elements within SVG images are updated to
not leak cross-origin data
// (e.g., visited links, spellcheck) we can remove the
SVGForeignObjectElement check here and
// research if we can remove the Image::hasSingleSecurityOrigin
mechanism entirely.

Does anyone know if there is any plan / bug report for this?

The FIXME comment misses a bug number, I can not find any bug entry on
Bugzilla (only the related bug 91523 and bug 131033) and I don't have
access to bug 119492...

Thank you,

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-15 Thread Frédéric WANG
Le 14/03/2016 23:34, Myles C. Maxfield a écrit :
> This is because we whitelist an explicit list of fonts which the tests
> are allowed to use. We don’t want tests to start failing just because
> the user has some unexpected font installed on their system. See
> allowedFontFamilySet() in Tools/DumpRenderTree/mac/DumpRenderTree.mm,
> Tools/WebKitTestRunner/InjectedBundle/cocoa/ActivateFontsCocoa.mm, and
> Tools/WebKitTestRunner/mac/TestControllerMac.mm 
Yes, that's the files Darin pointed out in his message. I tried it and
it worked great, thanks.
> We call CTFontManagerRegisterFontsForURLs(…
> kCTFontManasgerScopeProcess …) to make the fonts look like they are
> installed for just the local process. On iOS, we use the -sectcreate
> linker flag to place the font data directly inside the DumpRenderTree
> binary. We then create an in-memory CGFontRef backed by these bytes
> (the loader will put them in memory for us at process creation) we use
> CTFontManagerRegisterGraphicsFont() to make it look like it is
> installed. See activateTestingFonts() and activateFontIOS() in
> Tools/DumpRenderTree/mac/DumpRenderTree.mm.
I verified the fonts in the repo used by OS X / iOS.  As I see they are
duplicated in two places, their sizes are a few kilo bytes, they are
really test fonts (in the sense that they only have some artificial
glyphs and features) and no explicit license to restrict the usage (and
AHEM is in the public domain). I also see that fonts for specific
languages like "Corsiva Hebrew", "Devanagari MT" are in the whitelist so
I assume they are used for testing specific scripts.

So it seems that to be consistent with what is currently done, real open
source math fonts like Latin Modern Math and STIX Math would really go
into the list of allowedFontFamilySet but not in the WebKit repo. What
makes sense would be to put an artificial font in the repo to test math
features, but that's not so much different from the idea of using Web
fonts (and it is already done).

Anyway, for now I know how I can add custom fonts on iOS / OSX if that
turns out to be necessary or just for me to run tests locally ; and
Apple developers are aware of how to improve math rendering on their
ports. And as I said, I'll come back later on this math font topic when
more progress is made.

Thank you again.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-14 Thread Frédéric WANG
Le 13/03/2016 20:57, Darin Adler a écrit :
> I don’t think the size of the font files in the repository is a significant 
> issue; are the sizes particularly huge compared to the total size of all the 
> layout tests including expected results? If this was a problem, we could come 
> up with some other way of having the test machinery download the fonts, but I 
> think the complexity of that is not justified to solve a problem that may be 
> a non-problem.
My personal preference is to avoid putting (big) binary data inside
revision control system and instead generate or fetch them during the
build phase. Of course, sometimes you have to be pragmatic and it's more
convenient / easier to just put them in the repo. That's what we do for
example for the PNG test expectations, even though I don't like
polluting the WebKit patches with base64 data :-)

In addition, as I mentioned the OpenType fonts use LaTeX Project Public
License + Reserved Font Names and SIL OFL (copyleft + RFN) which may or
may not be compatible/convenient with the license of the WebKit project.
For example, I'm not even sure that with the current license of Latin
Modern Math it is possible to create a WOFF version without renaming it...

> Aside from the size of the font files, it seems like we have at least three 
> separate issues:
Thanks, I think I basically agree with these three points. It seems that
we went far away from my initial question (can we use custom fonts to
run Mac tests?). So I guess the next step for me will be to open a new
thread describing precisely the different features of MathML / Unicode /
OpenType that are used by WebKit, which math fonts support them or not
and what fallback we use or can use when math fonts are missing. Maybe
I'll wait the MathML refactoring to land and/or STIX2 to be released
before continuing the discussion.

I'd just like to highlight that in my opinion the rule of thumb would be
to treat math as other human languages (e.g. think to what happens with
Asian or Arabic scripts, ruby markup, OpenType features for complex text
layout etc). For example, just like normal text, CSS can be used on
MathML to select a math font and WebKit has to do its best to render
equations with that font or another system font and maybe finally a
non-font fallback (Gecko even has an internal "math" language to let
users customize the default and fallback fonts for MathML). The same
idea applies to pre-installed system fonts or layout tests.

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-12 Thread Frédéric WANG
Le 12/03/2016 17:04, Michael Catanzaro a écrit :
> Not sure I agree that WebKit should pull in any particular font
> package. I'd prefer to just add some math font that's installed by
> default. Other apps will want it too. 
Sure, that would be even better :-) Even if apps do not support the MATH
table, they would at least definitely need good unicode coverage for
math & tech characters instead of tofu...
> But it seems to depend on a bunch of perl and texlive packages:
> ...
> I'm hesitant to add texlive dependencies.
Mmh, yes that sounds bad. I just checked the fonts-lmodern package on
Debian (https://packages.debian.org/stretch/fonts-lmodern) and
unfortunately it depends on tex-common which correspond probably to all
the perl scripts you are asked to install :-(

I don't see why tex-common would be needed for packages that only
contain Open Type fonts. However, I suspect it's just that maintainers
have not considered a use of Latin Modern Math outside LaTeX so far.
Besides LuaTeX/XeTeX/ConTeXt the only open source math rendering engines
using OpenType MATH table are WebKit- and Gecko- based applications
(although Khaled Hosny plans to add support for this table in
GtkMathView and use it for math rendering in LibreOffice).

> Also, I don't see it in Font
> Viewer, so I guess it requires the fontconfig change suggested by that
> wiki page to work, and that would require coordination with fontconfig
> upstream. I suspect there is some good reason that texlive fonts are not 
> available to applications by default?
This depends on what distro / maintainer prefers. In Debian-base distro
the fontconfig changes are automatically done for Latin Modern Math, but
one Arch Linux user told me that their philosophy is rather to always do
the minimal setup and let users decide if they want to configure more ;
so the fontconfig change is unlikely to be done by default...

> Perhaps the easiest solution is to do nothing, and wait for a new STIX
> release?
I guess that's the easiest solution for Fedora...

However, in general I think the best would probably for distros to have
font packages independent from texlive that will just install the fonts
in more standard system locations and expose them to all apps by default...

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-12 Thread Frédéric WANG
Le 12/03/2016 02:01, Michael Catanzaro a écrit :
> Fred, if these fonts are not preinstalled, is MathML broken for users
> in practice? 
Yes, math fonts are fundamental as long as you start using relative
complex math (integrals, big fence & radicals etc) or deliver documents
to people used to high rendering quality (e.g. scientists familiar to
LaTeX). In the screenshot of my initial message you can see some obvious
problems like horizontal brace not stretching or ridiculously small
integral...
> If so, that would be a good argument for installing the fonts by default.
Well that's what I believe too, but apparently OS vendors have not been
convinced so far. I hope that can change for Apple when WebKit has
better math rendering... I'd already be happy if there is a simple way
to use the fonts for Mac testing, but otherwise I guess we should just
focus on the GTK port for now and continue to mark MathML tests as
failing on other ports...

> That's kinda my concern with this Latin Modern Math font we're using
> for the GTK port. We're not shipping that in Fedora and I doubt other
> distros are either, so if it's needed for MathML to work well, it's
> broken for users in practice. 
Most (all?) Linux distros have TeXLive packages which include Latin
Modern Math, XITS Math (a fork of STIX to fix existing bugs), and more
math fonts. So it's relatively easy for users to install the fonts.
Ideally, the Latin Modern package should be a dependency of WebKitGTK+,
which I think I (or Martin Robinson) already asked in the past to some
distro maintainers when we added Latin Modern Math to the test environment.

In the case of Fedora, the good news is that STIX is installed by
default in the normal setup. The bad news is that the current 1.1
release of STIX has many bugs making it bad for math layout albeit not
as bad as with the obsolete version shipped in OS X. However, I'm
confident the Fedora package will be updated to version 2 when it is
released.

See (*) for more details, which also gives an overview of the situation
in other operating systems. Given the lack of availability of math
fonts, workarounds have been considered but they add burden for each actor:

1) Web Engines: add fallback mechanisms e.g. scale transforms to stretch
the base size of operators (done in Gecko) or drawing them directly with
graphic functions (done in WebKit for radicals) etc However, people used
to high rendering quality find this kind of fallback particularly ugly.
Other people proposed to ship the big math fonts in the browsers, which
I believe would be sad...

2) Users: install fonts themselves or (specifically for mobile
platforms) install some browser addon providing them as Web fonts.

3) Authors: provide the math fonts as Web fonts on each website, ebook,
Web app etc

(*) https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-11 Thread Frédéric WANG
Le 11/03/2016 22:12, Myles C. Maxfield a écrit :
> Just to clarify: you want tests to use some specific fonts, but don’t
> want to check the fonts into the repository?
Yes. To test some specific OpenType MATH feature we already use our own
small fonts (a few kilobytes) loaded as Web fonts. However, for all the
other tests with real math fonts (where we want to get reliable
rendering and independent of which of these math fonts are installed or
not), it's not clear whether the license (compatibility with WebKit's?)
or the size (several hundreds of kilobytes) make that
possible/judicious. For WebKitGTK+ we have the separate repository of
fonts [3] mentioned in my previous mail that ensures Latin Modern Math
is available when running GTK tests.
> The downside to 1 is that it adds a new (non-obvious) step that all
> developers will have to perform every time they install a new
> operating system (in addition to any time we bring up a new buildbot).
> I would object to making the development environment even more
> complicated than it already is.
I agree with that. I'd just like to note that:

a) From my experience, installing user font in the Apple Font Book does
not even seem enough. For some reason, only the pre-installed font are
used when running tests...

b) As said above, WebKitGTK+ has a special mechanism to setup a jhbuild
environment and automate installation of dependencies ; I was wondering
if something similar exists for the Apple ports, but apparently that's
not the case...

> I’m not sure if I’m allowed to publicly discuss my opinions about 2
> (since it is technically an internal matter) but I would expect its
> success to be dubious.
Yes, I expected that. However, some years ago Apple accepted to install
the STIX font version 1.0. So I was hoping that maybe an upgrade to
version 2 when it is released would not be asking too much... at least
compared to the burden of managing a jhbuild-like mechanism in Apple
ports or bundling big fonts into the repo...

> Given this, I think the best solution is to check the fonts into the
> repository. Layout tests could target these as web fonts using
> @font-face, or they could use the same mechanism that we use for
> WebKitWeightWatcher (which is a font) to view the font as if it is
> preinstalled (without actually preinstalling it). 
Can you elaborate on what is done for WebKitWeightWatcher?

Thanks,

Frédéric



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Fonts for WebKit tests on OS X?

2016-03-11 Thread Frédéric WANG
*TL;DR: Can you please indicate how to add fonts to use for WebKit tests
on OS X? This is is needed for existing and future MathML tests (and
actually pre-installing them on Mac/iOS would improve user experience).*

Dear all,

In the context of the MathML refactoring [1], I've recently been
reviewing test results on OS X. Unfortunately, many of existing tests or
tests that will be added by the current set of MathML refactoring
patches require a math font with an OpenType MATH table to work
properly. This is not the case of the obsolete STIXGeneral font families
that have been installed by default since OS X Lion [2]. Hence for now
those tests are just skipped or have incorrect text/PNG expectations. As
a comparison, the GTK port uses the Latin Modern Math font to ensure
consistent results [3].

I'm attaching a simple test-fonts.html page and I'm providing the
screenshots obtained when I use run-safari or run-webkit-tests with a
WebKit build integrating the MathML refactoring patches. From this
experiment, it seems that run-webkit-tests only use the pre-installed
system fonts (STIXGeneral) but not the fonts I installed manually on my
Mac. However, the latter are correctly selected with run-safari and then
you can see that the rendering of math equations is much better and
closer to the TeX references from the MathML torture test [4].

So my question: is there a way to ensure that WebKit tests are executed
with specific fonts on OS X without polluting the WebKit repo with big
math Web fonts?

If the solution is to have these math fonts pre-installed on OS X, then
that would also be great to enhance Safari user experience, as shown by
the attached screenshots. In that case, this is probably not the
business of WebKit developers but I'd like to suggest two math fonts
(also reported to Apple some years ago as problems number 16841023 and
17021145):

1) STIX Math [5], which has very good coverage for unicode symbols, is
supported by some tech companies, is released under SIL OFL and is the
next version of the STIXGeneral font families currently pre-installed on
OS X. Unfortunately the current 1.1 release has too many bugs and so is
not really usable for math layout, but version 2 will solve them and is
claimed to be released "soon".

2) Latin Modern Math [6], which has the Computer Modern style used by
default by TeX rendering engines and is used for WebKitGTK+ tests. This
font uses the LaTeX Project Public License + a Reserved Font Name clause
but the authors expressed their will to release it under SIL OFL, if
that can help.

Thank you,

Frédéric

[1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
[2] https://bugs.webkit.org/show_bug.cgi?id=41961
[3] https://github.com/mrobinson/webkitgtk-test-fonts
[4]
https://developer.mozilla.org/en-US/docs/Mozilla_MathML_Project/MathML_Torture_Test
[5] http://stixfonts.org/
[6] http://www.gust.org.pl/projects/e-foundry/lm-math

Title: Test fonts


  
  

Basic font-family test:

  monospace: A
  STIXGeneral: A
  STIX Math: A
  Latin Modern Math: A



MathML Torture test 19:
  

  
x
+
...

+
x
  
  
⏞
k  times
  


  



MathML Torture test 14:
  


  
(

  
∂
2
  
  

∂

  x
  2

  

+


  
∂
2
  
  
∂


  y
  2

  

)
  

  

  |
  φ 
  (
  x
  +

  i
  y
  )
  |

2

  
  =
  0

  


Torture test 21:
  

  
∑

  p
   prime


  
  f
  (
  p
  )
  =

  
∫

  t
  >
  1

  

  f
  (
  t
  )
  
  d
  π
  (
  t
  )

  

  



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal: remove menclose notation radical

2016-03-10 Thread Frédéric WANG
Hi everyone,

As said in a previous message, MathML layout refactoring is in progress
[1] and I'd like to use this opportunity to propose removing support for
the menclose notation radical.

More context:

In MathML3 there are three ways to write roots:

  1)  child1 child2 ... child3 , equivalent to the LaTeX
expression \sqrt{child1 child2 ... child3} i.e. square root of "child1
child2 ... child3".
  2)  child1 child2 , equivalent to the LaTeX expression
\sqrt[child2]{child1} i.e. "child2"-th root of "child1".
  3)  child1 child2 ... child3 ,
equivalent to 1)

Currently 1) and 2) share an implementation in the RenderMathMLRoot
class. That implementation relies on anonymous renderers and flexbox
layout and has many issues with dynamic changes of child list, style,
zoom etc. However, I've uploaded a patch to do a complete refactoring of
RenderMathMLRoot in bug 153987 [2] which solves these issues.

The menclose element definitely needs a clean rewriting too. In
particular, 3) is implemented by appending an anonymous RenderMathMLRoot
child in which we put all the other children ; and again dynamic changes
are not handled very well . I have uploaded a patch to bug 155019 [3] in
order to completely rewrite the menclose implementation and I decided to
just remove support for menclose notation radical instead of trying to
reuse RenderMathMLRoot.

I expect this removal to be safe for the users given that (except in
examples and tests) I've always seen 1) preferred over 3) in math
documents. The only rationale for 3) would be to write overlapping
notations (e.g. )
but again I'm not aware of any concrete use case for that and it's
always possible to nest  and  to get similar rendering.
Finally, note that the accessibility code does expose the radical
notation and my patch for bug 155019 does not affect that code.

I plan to ask the same to Mozilla developers (FYI in Gecko, 1) and 3)
are implemented in the same class but 2) is implemented in a separate
class with duplicate code ; so it would also make sense for them to do a
simplification). In the future, I also plan to ask to the Math WG to
deprecate this notation and this is already done in the current draft of
the MathML in HTML5 implementation note I wrote [4]. Anyway, the MathML
recommendation is not too strict about supporting notation radical:
"Conforming renderers may ignore any value they do not handle, although
renderers are encouraged to render as many of the values listed below as
possible" [5].

Frédéric Wang

[1] https://lists.webkit.org/pipermail/webkit-dev/2015-December/027840.html
[2] https://bugs.webkit.org/show_bug.cgi?id=153987
[3] https://bugs.webkit.org/show_bug.cgi?id=155019
[4] http://www.mathml-association.org/MathMLinHTML5/
[5] https://www.w3.org/TR/MathML3/chapter3.html#presm.menclose




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MathML layout refactor proposal

2015-12-29 Thread Frédéric WANG
1).
Moreover, RenderMathMLScripts.[h|cpp] went down from 631 lines to 454
lines i.e. a ratio of 72%.
> MathML may not absolutely need all these, but several (like changing the 
> order for mroot) are very useful, and outlawing floats and columns and margin 
> collapsing is great for avoiding bugs or unintended interactions with other 
> code. So again by using flexbox, I think MathML can be thousands of lines 
> instead of tens of thousands of lines, and will need a lot less new tricky 
> lines to avoid buggy interactions with existing layout features and voodoo.
AFAIK, neither Gecko nor MathJax rely on flexboxes but just absolutely
place the math boxes (as we want to do in the new approach) and they are
able to get good math rendering. With hundred of lines, you can do a
pure CSS implementation (cf
https://github.com/fred-wang/mathml.css/blob/master/mathml.css) and
that's fine as long as you only expect low quality and limited support.
However, users want high-quality rendering similar to what is done in
TeX or Microsoft Word and so we need more flexibility to position math
boxes. Like for mmultiscripts, you can probably always add more and more
nested anonymous boxes but then the code becomes even more complex and
we spend too much time maintaining the integrity of the render tree
hierarchy instead of just focusing on arithmetic computations and simple
rules.

> Finally, I'd like to say that I think it's great that you guys are asking for 
> feedback on this. There are obviously webkit layout and rendering experts 
> that know a lot more than I do, and I urge you very strongly to try to get 
> one of them to help you with this design decision. Otherwise someone else in 
> a few years may delete your code, as has happened to me. :)
As Alejandro said, we are going to submit patches for review soon.
Additionally, we are really interested in hearing any feedback from
WebKit experts on the following implementation note and tests:

http://www.mathml-association.org/MathMLinHTML5/
http://tests.mathml-association.org/

Finally, I believe you are seeing the glass half empty if you reduce our
work to "deleting your code". I would rather say that the flexbox
implementation was an opportunity for developers/users to experiment
MathML in WebKit, improve our test suite, get feedback and discuss the
pros and cons of that approach. In particular, thanks to your work we
have a good idea of what would be acceptable by the Google reviewers in
the future. For now, we are just rewriting the MathML layout to address
the feedback from the WebKit community and get something better! Such a
refactoring happens everytime in software development, so there are no
reasons to worry...

-- 
Frédéric Wang



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] MathML layout refactor proposal

2015-12-14 Thread Frédéric WANG
Le 14/12/2015 19:39, Zalan Bujtas a écrit :
> It’s great to hear that MathML is getting some proper cleanup. I think the 
> proposal sounds good and I am looking forward to the patches. 
>
> Minor observation: I noticed that, since MathML block is no longer a flexbox, 
> but it still needs some of the flexbox functionality, the following pattern 
> has been introduced to the generic renderbox/block code. 
> -if (parent()->isFlexibleBox()) {
> +if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
> I just wish there was another way to handle this.
>
> Zalan.
Alex will correct me if I'm wrong, but I think the changes in RenderBox
are just a temporary solution to avoid breaking tests while we continue
to rewrite the MathML layout code. Hopefully, these won't be needed
anymore when we are done.

-- 
Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] How does WebKit accessibility code tell VoiceOver that a page has finished loading?

2015-10-01 Thread Frédéric WANG
Hi,

When Safari has finished loading a page, VoiceOver plays an ascending
three tone sound effect, selects the web document and starts reading the
page. I'm trying to reproduce this effect on Firefox for Mac (see
https://bugzilla.mozilla.org/show_bug.cgi?id=718637).

There is an old message on Apple mailing list indicating that the
application listening the notification must actually play the sound.
However, that does not seem to reply to the question since Gecko is the
sender of the notification, not the receiver:
http://prod.lists.apple.com/archives/accessibility-dev/2012/Apr/msg7.html

So instead I'm asking on this mailing list, since Gecko must probably
behave the same as WebKit. Reading WebKit source code, I found various
potential candidate notifications to send to VoiceOver:

@"AXLoadComplete"
@"AXLayoutComplete"
NSAccessibilityFocusedUIElementChangedNotification

I tried making Gecko call NSAccessibilityPostNotification with these
three events when the page is loaded and rendered but that does not seem
to help. The best I obtained is that the focus is now put on the web
document once it is loaded.

Any ideas about how WebKit accessibility code works here?

Thanks,

Frédéric Wang




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] How does WebKit accessibility code tell VoiceOver that a page has finished loading?

2015-10-01 Thread Frédéric WANG
On 10/02/2015 02:00 AM, Darin Adler wrote:
> I suggest normal Apple developer support channels. — Darin 
Thank you Darin.



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Reading Open Type tables in WebKit?

2014-03-21 Thread Frédéric WANG
Just to repeat what I said on the bug report, in case some Mac people 
have already tried to worked on that in the past ; the missing 
FontPlatformData::openTypeTable on Mac is also  preventing 
OPENTYPE_VERTICAL to be enabled on Mac and thus causing test failures 
for Japanese vertical text tests:


http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/TestExpectations#L542

--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


[webkit-dev] Adding ENABLE_OPENTYPE_MATH to WebCore

2014-03-21 Thread Frédéric WANG

Hi webkit-dev,

As mentioned in a previous thread 
(https://lists.webkit.org/pipermail/webkit-dev/2014-March/026373.html), 
I'm currently implementing the OpenType MATH table in WebKit (and Gecko) 
in order to improve the MathML rendering. This table is an extension of 
the TeX's layout rules (appendix G of the TeXBook) and was designed for 
the math support in Microsoft Word. Support for the MATH table has been 
implemented in modern TeX engines such as LuaTeX or XeTeX. The table can 
be edited with fontforge and is available in various math fonts. 
Finally, it is currently undergoing standardization in the MPEG group.


This support will be behind the ENABLE_OPENTYPE_MATH feature define. See:
https://bugs.webkit.org/show_bug.cgi?id=130324

References:

http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/call-proposals-isoiec-14496-22-open-font-format-color-font
http://www.ntg.nl/maps/38/03.pdf
http://www.fontforge.org/math.html
The MATH table and OpenType Features for Math Processing (Microsoft's 
document, not public yet ; ask me if you want to get a copy)


--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


[webkit-dev] Reading Open Type tables in WebKit?

2014-03-20 Thread Frédéric WANG

Hi all,

I'm trying to implement the OpenType MATH table [1] in WebKit in order 
to improve the MathML support. I've already made some progress and split 
the work into several steps [2]. For people who are interested, here are 
some screenshots showing some rendering improvements:


http://www.ulule.com/mathematics-ebooks/news/screenshots-31369/

There was already some code in 
Source/WebCore/platform/graphics/opentype/ to read OpenType tables so 
I've been able to reuse it for the MATH table. However, this code is not 
compiled on all platforms. At the moment I'm only able to compile the 
support for OpenType MATH table with the following condition:


USE(FREETYPE) || (PLATFORM(WIN)  (USE(CG) || USE(CAIRO)))

which I think means it will work on Linux (I tested the EFL and GTK 
ports) and most Windows platforms (not tested yet). This means that for 
the Mac port, I can not do better than using big hardcoded tables... 
That can be a temporary solution, but it would be better to read the 
font tables directly in order to get support for arbitrary MATH fonts 
and to make maintenance easier.


So I'd like to know if the current font API on the Mac port has some 
features to load OpenType tables? As a comparison on Gecko, I've used 
Harfbuzz to read the MATH table and this library is also available on 
Mac. I heard that Blink was moving to Harfbuzz on all platforms, so I'm 
also wondering if there are plans to do the same for WebKit? This would 
allow to support OpenType tables on all platforms...


Thank you,

[1] MATH table references:
http://mpeg.chiariglione.org/standards/mpeg-4/open-font-format/call-proposals-isoiec-14496-22-open-font-format-color-font
http://www.ntg.nl/maps/38/03.pdf
The MATH table and OpenType Features for Math Processing (Microsoft's 
document, not public yet ; send me a private mail if you want to get a copy)


[2] Bugzilla references:
https://bugs.webkit.org/show_bug.cgi?id=130321
https://bugs.webkit.org/show_bug.cgi?id=130322
https://bugs.webkit.org/show_bug.cgi?id=130324
https://bugs.webkit.org/show_bug.cgi?id=130325

--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


Re: [webkit-dev] Reading Open Type tables in WebKit?

2014-03-20 Thread Frédéric WANG

Hi,

Thanks. So to be more accurate, I think all what is needed is to 
implement FontPlatformData::openTypeTableon Mac to read the raw data:


http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/FontPlatformData.h#L219

Indeed, it looks like CTFontCopyTable is what we want. Then the parsing 
of the MATH table can be done normally using the existing
opentype code in WebKit: 
https://bugs.webkit.org/attachment.cgi?id=226905action=review


I'll email you a copy of MATH spec.

Le 20/03/2014 17:50, Chris Fleizach a écrit :

Hi,

In regards to the Mac platform we can use with CTFontCopyTable() with the MATH 
identifier.

Can you email me a copy of the Microsoft document so we can look into it more.

Thanks




--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

2014-03-12 Thread Frédéric WANG

git seems to work now, thanks.

However, http://trac.webkit.org/changeset is now blocked at revision 165462.

For some reason, 165462 does not appear on 
http://build.webkit.org/console but 165463 and 165464 are visible there.


Le 12/03/2014 10:12, Mark Rowe a écrit :

I’ve just fixed both trac.webkit.org and git.webkit.org. Please let us know if 
you notice any further issues.

Thanks,

- Mark

On Mar 11, 2014, at 23:53, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:


Additionally git.webkit.org is stucked too on r165452.

Osztrogonác Csaba írta:

Hi,
something is still wrong with trac.webkit.org, because it thinks
that the newest commit is http://trac.webkit.org/changeset/165452 ,
but the newest is r165460.
Could you check what happened? Thanks.
Ossy
Lucas Forschler írta:

Hello Webkit developers,

Apple will be upgrading our network infrastructure starting Tuesday morning at 
8am.
The webkit.org services will be affected for approximately 4 hours.

This includes all *.webkit.org domains.  We expect them to be back online 
before 12.

Thanks,
Lucas

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

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

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



--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

2014-03-12 Thread Frédéric WANG

Le 12/03/2014 11:06, Osztrogonác Csaba a écrit :

Frédéric WANG írta:

git seems to work now, thanks.

However, http://trac.webkit.org/changeset is now blocked at revision 
165462.

Maybe the post commit hook is still broken.

That seems to work now.



For some reason, 165462 does not appear on 
http://build.webkit.org/console but 165463 and 165464 are visible there.


Because r165462 wasn't committed to trunk, but 
releases/WebKitGTK/webkit-2.4 branch. It isn't bug.



Ah, OK thanks.

--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


[webkit-dev] Tracking WebKit changes needed documentation

2014-03-09 Thread Frédéric WANG

Hi,

I was discussing with some Mozillians at the MDN work week end and we 
were wondering how to keep track of changes in WebKit that require some 
documentation. For example, the Mozilla Bugzilla system has some 
keywords like dev-doc-needed and dev-doc-complete that MDN people 
can use to generate pages like


https://developer.mozilla.org/en-US/docs/MDN/Doc_status/CSS

so that people in charge of the documentation know what they must 
document or update.


In particular, we mentioned the case of MathML in WebKit for which new 
attributes/elements are currently being implemented and the browser 
compatibility tables will need to be updated e.g.

https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mo#Browser_compatibility
https://developer.mozilla.org/en-US/docs/Web/MathML/Element/mspace#Browser_compatibility

At the moment, I suggested to rely on the WebExposed keyword to find 
these kind of changes, but I'm not really sure what is the particular 
policy for that keyword to be set. For example, can I add this 
WebExposed keyword when I implement new MathML features? Other than 
MathML, are other new features systematically tagged with that keyword?


Do you have any suggestion for Bugzilla parameters that could help MDN 
people (and that the administrator of WebKit Bugzilla should add if 
necessary)? For example a keyword similar to dev-doc-complete to 
indicate when the documentation is done or to target milestone to 
indicate in which Safari version the changes will happen?


--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


Re: [webkit-dev] Tracking WebKit changes needed documentation

2014-03-09 Thread Frédéric WANG
Thank you Ryosuke. So I'll tell the MDN people that they can use the 
WebExposed keyword and will use it myself when I add new features to 
WebKit. I think the best the MDN people can do for the browser 
compatibility table is to get the list of WebExposed bugs and check if 
they landed in the latest version of Safari.


--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


[webkit-dev] Anonymous style (inheritance and dynamic update)

2014-02-04 Thread Frédéric WANG

Hi all,

I'm trying to refactor the MathML code to follow what seems the clean 
way to add style to elements and prepare for future improvements. Hence 
I have tried to do some experiments with anonymous style and that seems 
to work in some cases, but sometimes the style is not applied correctly. 
I don't know much about the WebKit layout code and just tried to copy 
what was done elsewhere. So I would appreciate if someone more familiar 
with the code base could check if the code makes sense and suggest the 
right way to implement that otherwise?


In https://bugs.webkit.org/show_bug.cgi?id=124838 I have attached a big 
patch that shares some code between the mi, mo and the mfenced 
elements (which uses anonymous mo), cleans up more things and tries to 
fix other rendering bugs. For convenience, I have extracted the changes 
that are only relevant to mi in a smaller patch: 
https://bug-124838-attachments.webkit.org/attachment.cgi?id=223101 (see 
in the new nsRenderMathMLToken class). The basic test case 
https://bug-44208-attachments.webkit.org/attachment.cgi?id=219653 
renders correctly with that patch but as I said above, other reftests 
fail for some reason.


Note that you don't need to know anything about MathML, but the 
following info might be helpful:


1) Single variables like mix/mi should be italic while multiple-char 
identifier like misin/mi should be upright ; the plan is thus to map 
this to CSS font-style (this is not quite what the MathML spec says but 
this approximation has been used in Gecko for a long time, so that's ok 
to use it in WebKit for now). Also in theory, whitespace should be 
collapsed in MathML tokens, so mi   x/mi is equivalent to 
mix/mi.


2) Operators like mo+/mo or mo(/mo may have different spacing. 
The default being indicated by the operator dictionary 
(http://www.w3.org/TR/MathML3/appendixc.html). The idea is to map this 
to margin-left/margin-right. This is what I try to do in the bigger 
patch https://bug-124838-attachments.webkit.org/attachment.cgi?id=222977 
as well as in the follow-up bug 
https://bugs.webkit.org/show_bug.cgi?id=99620.


Thank you,

--
Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks

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


[webkit-dev] Bugzilla editbugs-bit for fred DOT wang AT free DOT fr

2013-10-09 Thread Frédéric WANG

Hi all,

Could someone please give me the editbugs permission on Bugzilla?

Here are a few bugs I've been working on:

https://bugs.webkit.org/show_bug.cgi?id=115610
https://bugs.webkit.org/show_bug.cgi?id=99618
https://bugs.webkit.org/show_bug.cgi?id=116600
https://bugs.webkit.org/show_bug.cgi?id=118053
https://bugs.webkit.org/show_bug.cgi?id=118599
https://bugs.webkit.org/show_bug.cgi?id=106600
https://bugs.webkit.org/show_bug.cgi?id=120058
https://bugs.webkit.org/show_bug.cgi?id=85734
https://bugs.webkit.org/show_bug.cgi?id=85730

Thanks,

Frédéric Wang
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Bugzilla editbugs-bit for fred DOT wang AT free DOT fr

2013-10-09 Thread Frédéric WANG

Thank you!

Le 09/10/2013 09:53, Andreas Kling a écrit :
The following changes have been made to the user account 
fred.w...@free.fr mailto:fred.w...@free.fr:

• The account has been added to the editbugs group.

-Kling

On Oct 9, 2013, at 8:46 AM, Frédéric WANG fred.w...@free.fr 
mailto:fred.w...@free.fr wrote:



Hi all,

Could someone please give me the editbugs permission on Bugzilla?

Here are a few bugs I've been working on:

https://bugs.webkit.org/show_bug.cgi?id=115610
https://bugs.webkit.org/show_bug.cgi?id=99618
https://bugs.webkit.org/show_bug.cgi?id=116600
https://bugs.webkit.org/show_bug.cgi?id=118053
https://bugs.webkit.org/show_bug.cgi?id=118599
https://bugs.webkit.org/show_bug.cgi?id=106600
https://bugs.webkit.org/show_bug.cgi?id=120058
https://bugs.webkit.org/show_bug.cgi?id=85734
https://bugs.webkit.org/show_bug.cgi?id=85730

Thanks,

Frédéric Wang
___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev




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