[webkit-dev] Sammy Gill is now a WebKit Reviewer

[Brent Fulgham via webkit-dev]

Hi Folks!

I’m pleased to report that Sammy Gill is now a WebKit reviewer.

Sammy is well-versed in the Grid and Flex aspects of our rendering code, and is 
a great person to speak with about many of our new Interop and CSS features.

For now, he will be restricting his reviews to those bits of the layout and 
rendering stack he has the most experience.

Congratulations, Sammy!

Thanks,

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

Re: [webkit-dev] WebKit Documentation

[Brent Fulgham via webkit-dev]

I prefer (1)!On Mar 9, 2023, at 5:54 PM, Kirsling, Ross via webkit-dev  wrote:







I’d vote for (1) since it’s easy to type!
 
Thanks,
Ross
 

From: Ryosuke Niwa via webkit-dev 
Reply-To: Ryosuke Niwa 
Date: Friday, March 10, 2023 at 6:41 AM
To: Brandon Stewart 
Cc: Ling Ho via webkit-dev 
Subject: Re: [webkit-dev] WebKit Documentation


 


 






On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev  wrote:




 



Sorry for the delay on the documentation update.


 


For getting the documentation system online, we were trying to settle on a subdomain.


 


What would people prefer we use as the official documentation location:


(1) docs.webkit.org


(2) developer.webkit.org


(3) documentation.webkit.org






 


(1) or (3) seems good.


 


- R. Niwa


 






On Feb 28, 2023, at 12:39 AM, dpino via webkit-dev  wrote:



On 9/20/22 05:28, Brandon Stewart via webkit-dev wrote:

Hi WebKit Developers,
 
Documentation is an important part of any open source project, especially for a larger project like WebKit. Being able to ramp up during the onboarding process, reading up on architectural decisions, and learning how to perform common procedures are all features the documentation should tackle. WebKit has a large set of documentation already, but it is scattered around a wide range of platforms (Trac, GitHub Wiki, markdown files in the code, Git commits, etc...), and some of the information is out of date.
 
A few months ago, I started working on a new documentation solution based on the DocC documentation framework. This provides an easy way to add and edit documentation through markdown files. I have already ported a large section of Trac, all of the GitHub Wiki, and all of the non third party markdown files in the code over to this platform. I have tested this on macOS and Linux and have found it works extremely well. (Windows should be able to use WSL2 at the moment, while a few remaining issues get sorted out). The only dependency for this project is a recent installation of Swift.
 
You can already download the documentation and preview it locally, but we are looking to publish it online for easy viewing. We were looking to get your feedback if we would want to publish the documentation on GitHub Pages or webkit.org.
 
The documentation source can be found at https://github.com/webkit/documentation.
 
- Brandon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

H,
It has been more than 5 months since this new documentation repository was announced and as far as I know it hasn't been published yet. Is there any news when this site will be publicly available?
Right now in Igalia we need to publish some information publicly and we were discussing where it's the right place to put it.
  * WebKit Documentation (https://github.com/webkit/documentation.git),
 IMHO it doesn't make sense because the information needs to be public.
  * Trac (https://trac.webkit.org/wiki),
 since WebKit Documentation hasn't been published yet, the fact is that we have been updating Trac pages in the last months.
  * WebKit GitHub Wiki (https://github.com/WebKit/WebKit/wiki),
 it seems like the best candidate. It says that new documentation should live there instead of being added to Trac. But on the other hand when WebKit Documentation was announced some people advocated for keep using the GH Wiki but that idea was discarded. It
 seems like WebKit GitHub Wiki is were new documents should be published until WebKit Documentation site is not available? Please confirm whether this assumption is correct or not.
--
Diego

___
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 listwebkit-dev@lists.webkit.orghttps://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] Decommissioning the Apple Windows Port

[Brent Fulgham via webkit-dev]

Hi floks,

The time has come for Apple to decommission our Legacy version of the WebKit on 
Windows, shifting focus to the WinCairo port as the Windows target. The Apple 
port has long been a feature-locked, Legacy WebKit library that is increasingly 
difficult to maintain, and that holds back the rest of the project.

Over the coming days (or hours!?!), we intend to take the following actions:
Decommission our trunk builders and EWS infrastructure for Apple's Windows port 
(though the WinCairo Windows port will continue to be maintained).
Remove the Legacy WebKit code for Windows (long a goal of the WinCairo project!)
Begin removing the Apple-specific Windows code in the rest of the code base.
Remove references to older versions of CoreFoundation and CFNetwork, only 
retained for Windows use.
Users interested in WebKit for Windows should focus on the WinCairo port, which 
is a modern WebKit implementation with full multi-process features.

I’m discussing with the other WinCairo developers to see if we should rename 
that port to just, “Windows” to simplify messaging and documentation.

Please let me know if you have any comments or suggestions to improve our plan.

Best regards,

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

Re: [webkit-dev] WebKit Documentation

[Brent Fulgham via webkit-dev]

> On Sep 20, 2022, at 1:16 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> 
>> On Sep 19, 2022, at 2:28 PM, Brandon Stewart via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> Documentation is an important part of any open source project, especially 
>> for a larger project like WebKit. Being able to ramp up during the 
>> onboarding process, reading up on architectural decisions, and learning how 
>> to perform common procedures are all features the documentation should 
>> tackle. WebKit has a large set of documentation already, but it is scattered 
>> around a wide range of platforms (Trac, GitHub Wiki, markdown files in the 
>> code, Git commits, etc...), and some of the information is out of date.
> 
> This ultimately feels like this situation:
> https://xkcd.com/927/
> 
> I’ve been working on 
> https://github.com/WebKit/WebKit/blob/main/Introduction.md for the past 
> couple of years, and I’d would have preferred to have a collaboration rather 
> than a competition here.

Ryosuke: Your document is outstanding, and is a large part of the content we 
pulled into the current repo. I don’t think we view this as a competition; 
rather we are trying to host a collection of Markdown content in a common repo 
that does not have to be pulled and synced with WebKit source and tests. This 
provides a lower bar for people interested in contributing documentation as 
they do not have to download and sync Gigabytes of WebKit code to write 
documentation.
> 
>> A few months ago, I started working on a new documentation solution based on 
>> the DocC documentation framework.
> 
> Was there any discussion as to which documentation framework should be used? 
> I’m personally not familiar with DooC documentation, and I’m  surprised that 
> such an important decision was made unilaterally without much discussion on 
> webkit-dev.

We discussed this internally, but today’s message is the first discussion on 
this repository that we’ve opened on the webkit-dev mailing list. We wanted to 
convince ourselves that the tool worked well, and was easy to use, and could 
produce documentation output that would be useful for Apple engineers. That is 
not the only intended audience for this work, but is the origin of this effort 
which we wanted to make available to others to use and contribute to.

Those of us who have worked on WebKit for some time can easily remember the 
many discussions over the years about documentation efforts of various types. 
Lots of people have strong opinions, but few ever contribute despite their 
opinions of the right way for the work to be done. You are obviously part of 
the group that has contributed heavily, so I am sad that you do not seem to 
like our approach.

> 
>> I have already ported a large section of Trac, all of the GitHub Wiki, and 
>> all of the non third party markdown files in the code over to this platform.
> 
> I’m not certain if there is a community wide support that this is the right 
> tool to migrate all our documentations. I for one certainly object to the use 
> of DooC as the primary documentation tool.

DocC is one way of processing the Markdown content in this repo, and one that 
works well with Xcode since it creates output that matches Apple documentation 
style, and an output archive that can be consumed and used within Xcode search 
features.

There is nothing stopping an interested party using any of the other available 
Markdown-to-HTML tools to process the data in a way they prefer, much like 
WebKit sources can be built by Xcode, Visual Studio, and Make.


>> I have tested this on macOS and Linux and have found it works extremely 
>> well. (Windows should be able to use WSL2 at the moment, while a few 
>> remaining issues get sorted out). The only dependency for this project is a 
>> recent installation of Swift.
> 
> Previously, we’ve rejected Swift as a general purpose programming languages 
> in WebKit: 
> https://lists.webkit.org/pipermail/webkit-dev/2014-July/026722.html other 
> than to allow existing C++ code to call into Swift API: 
> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031882.html
> 
> As such, I don’t think we should require having a functional Swift toolchain 
> as a requirement for contributing to WebKit or its documentations either.

DocC is not a requirement to use or participate in this work. It’s simply a 
“port” of the documentation that works for our needs. If others prefer to 
“build” output documentation from Markdown using a different tool set, they are 
welcome to contribute those build commands and instructions.

Our goal is to accumulate all relevant and open source documentation related to 
WebKit in this repository so that we can generate searchable documentation. We 
would also like this to be accessible and searchable from the web.

Thanks,

-Brent

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

[webkit-dev] Proposed changes to Bugzilla 'Resolution' categories

[Brent Fulgham via webkit-dev]

Hi Floks,

I would like to propose some changes to the categories we use to resolve bugs. 
I’ve been trying to do some Bugzilla gardening to better reflect the state of 
various “edge case” bugs that often leave users confused about the state of 
issues they’ve reported, and unsure of whether fixes are needed or have been 
shipped.

Some of this is due to inertia, but some is due to lack of clarity in how to 
treat a few categories of bugs.

(1) Add a new “Behaves As Designed” option:

This will represent bugs that were filed when the reporter misunderstands a 
feature, or wants behavior that we have considered, but chosen not to allow.

This would be used instead of the somewhat offensive “WONTFIX” or mildly 
offensive “INVALID” resolutions we currently use.

(2) Add a new “Platform To Resolve” option:

This will represent bugs that are actually in an underlying component outside 
of sources in the WebKit project. This might be used to represent graphics 
driver bugs, kernel issues, platform User Interface libraries, or most 
frequently bugs in applications driving WebKit.

This would be used instead of the somewhat offensive ‘INVALID” resolution.

I’d like to hear thoughts on this idea, and whether people have improved labels 
or additional ideas in this space.

I’m hoping to improve the clarity of the information in Bugzilla, as well as 
have a more respectful tone to people that take the time to file bugs with us.

Thanks,

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

[webkit-dev] Intent to Remove: XSS Auditor

[Brent Fulgham via webkit-dev]

Hi Folks,

We have continued to ship the XSS Auditor for a number of years after Blink and 
other engines have abandoned this approach in favor of modern XSS defenses like 
CSP.

The XSS Auditor was a great idea in its day, but now poses a maintenance burden 
that far outweighs the small (perhaps nonexistent) benefit it provides.

We intend to remove the XSS Auditor in the coming weeks to better align with 
the behavior of other browsers.

Please let me know as soon as possible if you have reasons why this would be a 
significant issue for your port.

Best regards,

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

Re: [webkit-dev] Plugin process

[Brent Fulgham]

We haven’t removed it from Apple builds yet, because we think there are still 
some WebKit clients that use them. I.e., WebKit framework users on the platform 
that are not Safari or one of the other web browsers.

We should take another look, because it would be great to get rid of it 
completely.

Thanks,

-Brent

> 
> On Jul 19, 2020, at 11:12 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> Is anybody still using the plugin process? I understand that Safari does not 
> allow plugins anymore. Epiphany doesn't either, nor does anything packaged in 
> Linux distros  (afaik). If nothing is using it, maybe we can delete a lot of 
> code? Is it exposed in Apple system APIs?
> 
> WebKitGTK still has an enable-plugins setting that is not yet deprecated. 
> Probably long past time to at least deprecate it. There's also, incredibly, 
> an enable-java setting, which I presume toggles the old Java browser plugin. 
> I sense there must be some history behind that setting. :)
> 
> 
> ___
> 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] Introducing a minimum ICU version for WebKit

[Brent Fulgham]

Please note that Per Arne updated the Apple ZIP files to have the correctly 
aligned ICU libraries, so the Windows bots should have what they need.

I apologize for taking so long to complete that.

Thanks,

-Brent

> On Apr 3, 2020, at 4:57 PM, Ryosuke Niwa  wrote:
> 
> 
> On Fri, Apr 3, 2020 at 4:25 PM Kirsling, Ross  > wrote:
> Hi everybody,
> 
>  
> 
> Just sending out an email blast for visibility regarding 
> https://bugs.webkit.org/show_bug.cgi?id=209694 
> .
> 
>  
> 
> This patch:
> 
> Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
> matching Mojave
> Introduces a minimum ICU version of 60.2 throughout the codebase, as required 
> by GTK for Ubuntu 18.04 LTS
>  
> 
> As written in the ChangeLog, the immediate motivations are:
> 
> To properly establish a minimum ICU version for WebKit as a whole
> (responding to a pain point identified in 
> https://bugs.webkit.org/show_bug.cgi?id=209579 
> )
> To support the development of ECMA-402 Intl API features, which JSC is quite 
> behind on
> (and which often boil down to exposing ICU functionality to JavaScript)
>  
> 
> The only remaining concern of which I am aware is that AppleWin’s ICU 
> headers, stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 
> 49 to 62 (to match the lib files stored in WebKitSupportLibrary.zip). We do 
> have a potential workaround for this (i.e. having CMake copy the Mac headers 
> to WebKitLibraries/win) but it is feared that this may break Apple-internal 
> builds and we would certainly like to avoid a revert if possible. Any help on 
> this front would be greatly appreciated.
> 
> 
> FWIW, I've been told that Brent / Per might be able to help you there but 
> might need some more time due to other more urgent commitments.
> 
> - R. Niwa
> 
> ___
> 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] Proposal: add Privacy to WebKit Project Goals

[Brent Fulgham]

I think this looks great!
-Brent

> On Feb 23, 2020, at 5:02 PM, Maciej Stachowiak  wrote:
> 
> 
> V2, with stronger privacy language.
> 
> 
> project-new.html
>   WebKit is an open source Web content engine for browsers and other 
> applications.
> 1212
> 1313
> 14 We value real-world web compatibility, standards compliance, stability, 
> performance, security, portability, usability, and relative ease of 
> understanding and modifying the code (hackability).
>  14We value real-world web compatibility, standards compliance, stability, 
> performance, battery life, security, privacy, portability, usability, and 
> relative ease of understanding and modifying the code (hackability).
> 1515Project Goals
> 1616Web Content Engine
> 17 The project’s primary focus is content deployed on the World Wide Web, 
> using standards-based technologies such as HTML, CSS, JavaScript and the DOM. 
> However, we also want to make it possible to embed WebKit in other 
> applications, and to use it as a general-purpose display and interaction 
> engine.
>  17The project’s primary focus is content deployed on the World Wide Web, 
> using standards-based technologies such as HTML, CSS, JavaScript and DOM. 
> However, we also want to make it possible to embed WebKit in other 
> applications, and to use it as a general-purpose display and interaction 
> engine.
> 1818Open Source
> 1919WebKit should remain freely usable for both open source and 
> proprietary applications. To that end, we use BSD-style and LGPL licenses. 
> Specifically, we aim for licensing compatible with LGPL 2.1+. We do not 
> currently plan to move to LGPL 3. In addition, we strive to create a 
> courteous, welcoming environment that feels approachable to newcomers. WebKit 
> maintains a public IRC chat room and a public mailing list where the ideas of 
> contributors both new and old are heard and discussed with equal weight.
> 2020Compatibility
> 
> 2424Stability
> 2525The main WebKit code base should always maintain a high degree of 
> stability. This means that crashes, hangs and regressions should be dealt 
> with promptly, rather than letting them pile up.
> 2626Performance
> 27 Maintaining and improving speed and memory use is an important goal. We 
> never consider performance “good enough”, but strive to constantly improve. 
> As web content becomes richer and more complex, and as web browsers run on 
> more limited devices, performance gains continue to have value even if normal 
> browsing seems fast enough.
>  27Maintaining and improving speed and memory use is an important goal. We 
> never consider performance “good enough”, but strive to constantly improve. 
> As web content becomes richer and more complex, and as web browsers run on 
> more limited devices, performance gains continue to have value even if normal 
> browsing seems fast enough. We consider speed, memory use, responsiveness and 
> frame rate to be important aspects of performance.
>  28Battery Life
>  29In addition to traditional performance metrics, we aim to minimize 
> power consumption to maximize browsing battery life for portable devices.
> 2830Security
> 2931Protecting users from security violations is critical. We fix security 
> issues promptly to protect users and maintain their trust.
>  32Privacy
>  33We believe privacy is a human right. WebKit code won't track the user 
> or otherwise violate their privacy. And we will strive to prevent websites 
> and other parties from doing so.
> 3034Portability
> 3135The WebKit project seeks to address a variety of needs. We want to 
> make it reasonable to port WebKit to a variety of desktop, mobile, embedded 
> and other platforms. We will provide the infrastructure to do this with tight 
> platform integration, reusing native platform services where appropriate and 
> providing friendly embedding APIs.
> 3236Usability

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

Re: [webkit-dev] Proposal: add Privacy to WebKit Project Goals

[Brent Fulgham]

> On Feb 16, 2020, at 12:39 PM, Maciej Stachowiak  wrote:
> 
> 
> There hasn’t been any feedback on this, so below is a proposed change (in 
> PrettyPatch HTML format) to  >.
> 
> In addition to adding Privacy as a goal, I also added Battery Life, and 
> tweaked a few of the existing goals.
> 
> Thoughts?
> 
> 
> project-new.html
> 
>  32Privacy
>  33Users want their privacy respected. We avoid directly violating the 
> user's privacy, and strive to prevent websites and other parties from doing 
> so.

The term “directly violating” sounds a little soft. Do we not care about 
indirect privacy violations?

I don’t know the right wording to use, but I would like to say something along 
the lines of:

“Users want their privacy respected. We avoid violating the user’s privacy, and 
strive to prevent websites and other parties form doing so, too. We view the 
UserAgent’s primary responsibility to be protecting the interests of the user. 
We therefore do not support or intend to implement web standards that are at 
odds with these goals, or that create mechanisms to fingerprint or otherwise 
monitor user behavior.”

Thanks,

-Brent


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

Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

[Brent Fulgham]

Apple is in the process of bringing up VS2019 now. I would be in favor of 
moving the minimum to 3.14 so we can safely support VS2019 compiles.

-Brent

> On Jun 24, 2019, at 8:21 PM, Fujii Hironori  wrote:
> 
> Hi,
> 
> I'm going to bump cmake_minimum_required version to 3.10 for
> shining new features.
> 
> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
> https://bugs.webkit.org/show_bug.cgi?id=199181 
> 
> GTK and WPE's EWS and BuildBot bots maintainers, could you please
> update your CMake on your bots?
> 
> If you are using CMake Visual Studio generator, you need CMake
> 3.12 or newer to avoid an unnecessary recompilation issue.
> 
> AppleWin port seems still using old Visual Studio 2017. If it
> will switch to Visual Studio 2019 for better C++17 support,
> Visual Studio 2019 needs CMake 3.14 or newer.
> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>  
> Happy WebKit 18th  
> birthday  
> 🎂
> 
> -- Fujii
> ___
> 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] New iOS versions sending bogus User-Agent build data

[Brent Fulgham]

Hi Colin,

> On Apr 26, 2018, at 8:57 AM, Colin Bendell | +1.613.914.3387 
>  wrote:
> 
> […] images to a device. I have a laundry list of other examples where the
> server might actually know more than the client to prevent a) a broken
> user experience and b) prevent cellular data waste.

Would you mind documenting those items in a Bugzilla report? We are interested 
in specific use cases that suffer with a frozen user agent string, and what 
(apparently bad) techniques you need to use to work around it.

Thanks,

-Brent



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

Re: [webkit-dev] HSTS user tracking

[Brent Fulgham]

Sure — I’ll ask Jon to get it scheduled to post.

> On Mar 1, 2018, at 11:50 AM, Maciej Stachowiak  wrote:
> 
> 
> 
>> On Mar 1, 2018, at 10:44 AM, Michael Catanzaro  wrote:
>> 
>> On Fri, Jan 5, 2018 at 3:11 PM, Brent Fulgham  wrote:
>>> I´m sorry we haven´t been forthcoming with details. We have wanted to put 
>>> together a blog post explaining our fix, but have been preoccupied with a 
>>> number of other security issues.
>>> I will make this my top priority, or at least give a rough overview to the 
>>> webkit-security folks if we can´t put together a blog-worthy document fast 
>>> enough.
>>> Thanks,
>>> -Brent
>> 
>> Hi,
>> 
>> It'd still be great to get some details about your strategy for mitigating 
>> user tracking via HSTS.
>> 
>> It should be suitable for webkit-dev, rather than the private security list, 
>> right?
> 
> I think we should still publish the blog post, if it's at all close to ready. 
> Brent?
> 
> - Maciej
> 

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

Re: [webkit-dev] HSTS user tracking

[Brent Fulgham]

I’m sorry we haven’t been forthcoming with details. We have wanted to put 
together a blog post explaining our fix, but have been preoccupied with a 
number of other security issues.

I will make this my top priority, or at least give a rough overview to the 
webkit-security folks if we can’t put together a blog-worthy document fast 
enough.

Thanks,

-Brent

> On Jan 5, 2018, at 12:58 PM, Maciej Stachowiak  wrote:
> 
> 
> Brent Fulgham or John Wilander would know the details.
> 
> - Maciej
> 
>> On Jan 5, 2018, at 8:04 AM, Michael Catanzaro  wrote:
>> 
>> 
>> Hi devs,
>> 
>> Any info about how to mitigate this problem would be appreciated. Thanks!
>> 
>> Michael
>> 
>> ___
>> 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] RFC: stop using std::chrono, go back to using doubles for time

[Brent Fulgham]

EWS Hates your patch! :-)

> On Nov 4, 2016, at 10:01 AM, Filip Pizlo  wrote:
> 
> Hi everyone!
> 
> That last time we talked about this, there seemed to be a lot of agreement 
> that we should go with the Seconds/MonotonicTime/WallTime approach.
> 
> I have implemented it: https://bugs.webkit.org/show_bug.cgi?id=152045 
> 
> 
> That patch just takes a subset of our time code - all of the stuff that 
> transitively touches ParkingLot - and converts it to use the new time 
> classes.  Reviews welcome!
> 
> -Filip
> 
> 
> 
>> On May 22, 2016, at 6:41 PM, Filip Pizlo > > wrote:
>> 
>> Hi everyone!
>> 
>> I’d like us to stop using std::chrono and go back to using doubles for time. 
>>  First I list the things that I think we wanted to get from std::chrono - 
>> the reasons why we started switching to it in the first place.  Then I list 
>> some disadvantages of std::chrono that we've seen from fixing 
>> std::chrono-based code.  Finally I propose some options for how to use 
>> doubles for time.
>> 
>> Why we switched to std::chrono
>> 
>> A year ago we started using std::chrono for measuring time.  std::chrono has 
>> a rich typesystem for expressing many different kinds of time.  For example, 
>> you can distinguish between an absolute point in time and a relative time.  
>> And you can distinguish between different units, like nanoseconds, 
>> milliseconds, etc.
>> 
>> Before this, we used doubles for time.  std::chrono’s advantages over 
>> doubles are:
>> 
>> Easy to remember what unit is used: We sometimes used doubles for 
>> milliseconds and sometimes for seconds.  std::chrono prevents you from 
>> getting the two confused.
>> 
>> Easy to remember what kind of clock is used: We sometimes use the monotonic 
>> clock and sometimes the wall clock (aka the real time clock).  Bad things 
>> would happen if we passed a time measured using the monotonic clock to 
>> functions that expected time measured using the wall clock, and vice-versa.  
>> I know that I’ve made this mistake in the past, and it can be painful to 
>> debug.
>> 
>> In short, std::chrono uses compile-time type checking to catch some bugs.
>> 
>> Disadvantages of using std::chrono
>> 
>> We’ve seen some problems with std::chrono, and I think that the problems 
>> outweigh the advantages.  std::chrono suffers from a heavily templatized API 
>> that results in template creep in our own internal APIs.  std::chrono’s 
>> default of integers without overflow protection means that math involving 
>> std::chrono is inherently more dangerous than math involving double.  This 
>> is particularly bad when we use time to speak about timeouts.
>> 
>> Too many templates: std::chrono uses templates heavily.  It’s overkill for 
>> measuring time.  This leads to verbosity and template creep throughout 
>> common algorithms that take time as an argument.  For example if we use 
>> doubles, a method for sleeping for a second might look like 
>> sleepForSeconds(double).  This works even if someone wants to sleep for a 
>> nanoseconds, since 0.01 is easy to represent using a double.  Also, 
>> multiplying or dividing a double by a small constant factor (1,000,000,000 
>> is small by double standards) is virtually guaranteed to avoid any loss of 
>> precision.  But as soon as such a utility gets std::chronified, it becomes a 
>> template.  This is because you cannot have sleepFor(std::chrono::seconds), 
>> since that wouldn’t allow you to represent fractions of seconds.  This 
>> brings me to my next point.
>> 
>> Overflow danger: std::chrono is based on integers and its math methods do 
>> not support overflow protection.  This has led to serious bugs like 
>> https://bugs.webkit.org/show_bug.cgi?id=157924 
>> .  This cancels out the 
>> “remember what unit is used” benefit cited above.  It’s true that I know 
>> what type of time I have, but as soon as I duration_cast it to another unit, 
>> I may overflow.  The type system does not help!  This is insane: std::chrono 
>> requires you to do more work when writing multi-unit code, so that you 
>> satisfy the type checker, but you still have to be just as paranoid around 
>> multi-unit scenarios.  Forgetting that you have milliseconds and using it as 
>> seconds is trivially fixable.  But if std::chrono flags such an error and 
>> you fix it with a duration_cast (as any std::chrono tutorial will tell you 
>> to do), you’ve just introduced an unchecked overflow and such unchecked 
>> overflows are known to cause bugs that manifest as pages not working 
>> correctly.
>> 
>> I think that doubles are better than std::chrono in multi-unit scenarios.  
>> It may be possible to have std::chrono work with doubles, but this probably 
>> implies us writing our own clocks.  std::chrono’s default clocks use 
>> integers, not doubles.  It also may be possible to teach std::chrono to do 
>> overflow prot

Re: [webkit-dev] WebKit GPU rendering possibility

[Brent Fulgham]

I would suggest “http://browserbench.org/MotionMark 
”. :-)

-Brent

> On Nov 3, 2016, at 12:17 PM, Rogovin, Kevin  wrote:
> 
> Hi,
> 
> What are some good 2D UI graphics benchmarks that are cross-platform-ish? I'd 
> think I need to port them to Fast UI Draw, but that is possible.
> 
> I am very confident that Fast UI Draw will perform at the top by a large 
> margin. The more complicated and heavier the load, the better it will do.
> 
> -Kevin
> 
> -Original Message-
> From: mmaxfi...@apple.com [mailto:mmaxfi...@apple.com] 
> Sent: Thursday, November 3, 2016 9:07 PM
> To: Rogovin, Kevin 
> Cc: Carlos Garcia Campos ; webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> It sounds like the primary focus of your work is improving performance. It 
> also sounds like the only benchmark you’ve run is an artificial one that you 
> constructed yourself.
> 
> Given these two things, I would strongly hesitate to call our interest 
> "significant community enthusiasm.”
> 
> Why don’t you start by running some of the many existing graphics benchmarks 
> with your library?
> 
> Please correct me if my assumptions are mistaken.
> 
> Thanks,
> Myles
> 
>> On Nov 3, 2016, at 12:50 AM, Rogovin, Kevin  wrote:
>> 
>> Adding a new GraphicsContext is what I want to do as it seems the path of 
>> least pain and suffering. However, all the other things of a backend I do 
>> not need to do. I do not know how to add a GraphicsContext backend in terms 
>> of makefile magicks and configuration. I also do not know the plumbing for 
>> making it active. In theory, FastUIDraw's GraphicsContext will work on any 
>> platform that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do 
>> this? Years ago I remember that the build configuration is what governed 
>> what backend was built... and I usually just piggy packed onto another... 
>> years ago I remember there was like an SDL style backend that did not 
>> require a large toolkit, just SDL.. is that still alive? where is it? I 
>> could piggy back the work there if it still is alive...
>> 
>> Also, to get permission to do this work, I need significant community 
>> enthusiasm otherwise I will not be able to justify the large amount of work 
>> needed. This is another area where I need a great deal of help.
>> 
>> Best Regards,
>> -Kevin Rogovin
>> 
>> -Original Message-
>> From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
>> Sent: Thursday, November 3, 2016 9:43 AM
>> To: Rogovin, Kevin ; Myles C. Maxfield 
>> 
>> Cc: webkit-dev@lists.webkit.org
>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>> 
>> El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
>>> Hi,
>>> 
>>> The main issue of making a Cairo backend to FastUIDraw is clipping.
>>> Cairo tracks the clipping region in CPU and does things that are fine 
>>> for CPU-based rendering (i.e. span based rendering) but are 
>>> absolutely awful for GPU rendering (from my slides, one sees that GL 
>>> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw 
>>> only supports clipIn and clipOut and pushes all the clipping work to 
>>> the GPU with almost no CPU work. It does NOT track the clipping 
>>> region at all. I can give more technical details how it works (and 
>>> those details are why FastUIDraw cannot be used a backend for Cairo).
>>> For those interested in where the code is located for clipping in 
>>> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
>>> methods clipInRect, clipOutPath and clipInPath. Their implementations 
>>> are very short and simple and are quite cheap on CPU.
>> 
>> I see. Then I guess adding a new GraphicsContext for FastUIDraw is the 
>> easiest and best way to try this out in WebKit. Would it be possible to  
>> just add a new GraphicsContext implementation? or would you also need to 
>> change other parts of the graphics implementation or the GraphicsContext API 
>> itself?
>> 
>>> Best Regards,
>>> -Kevin
>>> 
>>> -Original Message-
>>> From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
>>> Sent: Thursday, November 3, 2016 9:27 AM
>>> To: Rogovin, Kevin ; Myles C. Maxfield >> fi...@apple.com>
>>> Cc: webkit-dev@lists.webkit.org
>>> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
>>> 
>>> El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
 Hi!
 
 Question answers:
 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL 
 ES 3.0. One of its design goals is to make it not terribly awful to 
 write a backend to different 3D API’s.
 2.  I think I was unclear in my video. I have NOT migrated ANY 
 UI rendering library to use Fast UI Draw. What I have done is made a 
 demo
 (painter-cells) and ported that demo to Fast UI Draw, Cairo, Qt’s 
 QPainter and SKIA. The diffs between the ports is almost trivial (it 
 really is just using those different r

Re: [webkit-dev] Proposal: Remove Battery Status API code

[Brent Fulgham]

I strongly support the proposal to remove this API.

-Brent

> On Oct 30, 2016, at 5:54 PM, Simon Fraser  wrote:
> 
> I support the proposal to remove.
> 
> Simon
> 
>> On Oct 30, 2016, at 5:14 PM, Brady Eidson  wrote:
>> 
>> 
>> There's code in the tree to support the W3C Battery Status API.
>> 
>> A recent study showed the extent of the risk (discussion and link to study 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.lukaszolejnik.com_battery-2Dstatus-2Dreadout-2Das-2Da-2Dprivacy-2Drisk_&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI&m=ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI&s=8c9qMq7SAf9mAh8t9oHbJE45_tXRsbZBMid46hd9UXs&e=
>>  ) which led to Mozilla first making the API less precise 
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1124127) but then eventually 
>> removing it altogether (https://bugzilla.mozilla.org/show_bug.cgi?id=1313580)
>> 
>> Apple has never enabled this on their ports, one reason being concern for 
>> abuse in fingerprinting/tracking. 
>> The study seems to be a strong second opinion backing this concern.
>> Mozilla's actions demonstrate another vendor not seeing the API being useful 
>> enough to outweigh the user concern.
>> 
>> As one of the voices for Apple's ports I think the above episode further 
>> cements our concern in ever enabling the API.
>> 
>> As one of the voices for WebKit as a whole I think above episode suggests we 
>> should just remove the code from the tree altogether.
>> 
>> What to other Apple folks think? What do port maintainers who enable the API 
>> think?
>> 
>> Thanks,
>> ~Brady
> 
> ___
> 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] WinCairo Maintainers

[Brent Fulgham]

> On Sep 26, 2016, at 12:55 PM, Olmstead, Don  wrote:
> 
> @annulen I know you've mentioned conan.io before but I've never personally 
> used it so I'm not sure how well it would fit with everything. It's something 
> we can take a look at beforehand and see what it would take vs the single 
> repository setup.
> 
> @alexchristensen I can make a GitHub org  push the repository to it and then 
> start using GitHub releases to host the final binary.
> 
> Do either of you know of anyone who is shipping a product based on WinCairo 
> though?

1. Electronic Arts uses the WinCairo/Cairo backend as the basis for their port, 
though I’m not sure how closely it follows the upstream sources. I believe they 
do use Cairo for drawing, but do not use the Linux or Windows-specific WebKit 
code paths.

They seem pretty quiet on the list lately, though they are on the 
webkit-security list and seem to respond to notes on that list.

2. Wyatt Technology used WinCairo for its reporting tool in its ASTRA software 
>. As far as I know they are 
still using it, though I’m not sure how up-to-date their copy of the library is.

I think Alex knows of at least one other user out there.

Thanks,

-Brent



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

Re: [webkit-dev] MathML refactoring: Project Complete!

[Brent Fulgham]

Thank you for all of this work, Frédéric! I don’t think our WebML rendering has 
ever looked so good! :-)

-Brent

> On Jul 13, 2016, at 10:22 AM, Frédéric WANG  wrote:
> 
> 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
> 
> 
> ___
> 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] Windows Bot Updates

[Brent Fulgham]

Hi Everyone,

I have just reviewed the full set of Windows EWS and build bots, and updated 
them as follows:

1. Perl 5.18 or newer, which matches the Perl shipped with Mac OS.
2. Visual Studio 2015, Update 2. This fixes a number of C++ compatibility 
issues.

At this point, it should not be necessary to have Windows-specific C++ hacks in 
the code.

Most of the places where I knew we had worked around VC++ compiler bugs were 
commented. We have now removed all such commented hacks.

Please let me know if you are aware of any other cases where we were forced to 
use less efficient or more complicated code to work around an issue with Visual 
C++. We should be able to remove those hacks now.

Thanks,

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

Re: [webkit-dev] Is someone going to fix Windows EWS?

[Brent Fulgham]

This is happening because “Font.h” is referring to 
“”, which doesn’t always exist on Windows at the 
time the file is compiled. The CoreGraphicsSPI.h file lives in 
“WebCore/platform/spi/cg/CoreGraphicsSPI.h”, and can be found with a normal 
‘#include “CoreGraphicsSPI.h”. It’s only after a post-build step copies the 
file to “DerivedSources/ForwardingHeaders/WebCore/CoreGraphicsSPI.h” that the 
‘#include ” form works.

When a non-clean build is performed, this is fine, so EWS probably works 
properly most of the time. But if something prompts it to clean the build 
output, the file doesn’t exist and the build fails, improperly blaming the 
current patch.

I’ll talk to Alex about the copy phase of these headers and see if we can get 
this into proper position earlier.

Thanks,

-Brent


> On Mar 30, 2016, at 9:28 AM, Alexey Proskuryakov  
> wrote:
> 
> 
> They fail like this: 
> https://webkit-queues.webkit.org/queue-status/win-ews/bots/ews202https://webkit-queues.webkit.org/results/1069527
> 
> c:\cygwin\home\buildbot\webkit\source\webcore\platform\graphics\Font.h(57): 
> fatal error C1083: Cannot open include file: 'WebCore/CoreGraphicsSPI.h': No 
> such file or directory (compiling source file 
> C:\cygwin\home\buildbot\WebKit\Source\WebCore\DerivedSources.cpp) 
> [C:\cygwin\home\buildbot\WebKit\WebKitBuild\Release\Source\WebCore\WebCoreDerivedSources.vcxproj]
> 
> It's quite surprising that the build passes after rolling out a patch, thus 
> making EWS think that the patch is to blame. 
> 
> - Alexey
> 
> 
> 
>> 30 марта 2016 г., в 9:20, Brent Fulgham  написал(а):
>> 
>> Aside from ews206 being offline for some reason, all bot seem to be running 
>> without any errors.
>> 
>> Can you point me at a couple of the patches you were looking at? I 
>> spot-checked a couple in the Review Queue and they seemed to be failing for 
>> legitimate problems with the patches.
>> 
>> Thanks,
>> 
>> -Brent
>> 
>>> On Mar 30, 2016, at 9:04 AM, Brent Fulgham  wrote:
>>> 
>>> Looking now.
>>> 
>>> -Brent
>>> 
>>>> On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
>>>> 
>>>> Every patch I look at has a red bubble for Windows on EWS. Is someone 
>>>> planning on fixing this?
>>>> 
>>>> — 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
> 
> 

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

Re: [webkit-dev] Is someone going to fix Windows EWS?

[Brent Fulgham]

Aside from ews206 being offline for some reason, all bot seem to be running 
without any errors.

Can you point me at a couple of the patches you were looking at? I spot-checked 
a couple in the Review Queue and they seemed to be failing for legitimate 
problems with the patches.

Thanks,

-Brent

> On Mar 30, 2016, at 9:04 AM, Brent Fulgham  wrote:
> 
> Looking now.
> 
> -Brent
> 
>> On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
>> 
>> Every patch I look at has a red bubble for Windows on EWS. Is someone 
>> planning on fixing this?
>> 
>> — 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] Is someone going to fix Windows EWS?

[Brent Fulgham]

Looking now.

-Brent

> On Mar 30, 2016, at 9:02 AM, Darin Adler  wrote:
> 
> Every patch I look at has a red bubble for Windows on EWS. Is someone 
> planning on fixing this?
> 
> — 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

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

[Brent Fulgham]

> On Mar 9, 2016, at 5:27 PM, Anders Carlsson  wrote:
> 
> I propose that we instead start using
> 
> #pragma once

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

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Brent Fulgham]

+1. I am in favor of this as well!

-Brent

> On Mar 3, 2016, at 11:23 AM, Saam barati  wrote:
> 
> +1.
> I like how “override” only reads.
> 
> Saam
> 
>> On Mar 3, 2016, at 9:54 AM, Ryosuke Niwa  wrote:
>> 
>> I think "virtual" + "override" is more of a historical artifact than
>> the preferred style because we used to have OVERRIDE macro before all
>> compilers supported C++11.  I think we should just use only "override"
>> going forward.
>> - R. Niwa
>> 
>> 
>> On Thu, Mar 3, 2016 at 9:38 AM, Darin Adler  wrote:
>>> Antti proposed using only “override” a while back since it’s less verbose 
>>> and still unambiguous. I don’t think we reached consensus on which style to 
>>> prefer for the project, though.
>>> 
>>> — 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

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

[webkit-dev] Crash Traces on Windows Now Functional

[Brent Fulgham]

Hi Folks!

Our Windows test bots have long been unable to produce usable stack traces when 
crashes were encountered. I’m pleased to announce that I finally fixed this 
problem.

Now that this is working, I would appreciate your help:

1. Please let me know if you see crashes happening on Windows, but do not find 
a relevant stack trace.
2. Please let me know if the stack trace for a crash seems unrelated to the 
test it is associated with.
3. Finally, please use the stack traces to help fix any crashes introduced by 
your changes! :-)

Thanks,

-Brent


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

Re: [webkit-dev] CMake on Windows

[Brent Fulgham]

Hi Youenn,

We are using native CMake from the Windows command line, though I believe the 
Cygwin version should work.

I have a longer-term goal of being able to do development without requiring 
Cygwin, though we are a long way from achieving that just yet.

Thanks,

-Brent

> On Sep 29, 2015, at 12:36 AM, youenn fablet  wrote:
> 
> Awesome !
> 
> Quick question: is CMake used from cygwin?
> Also, is there a current/future Windows build efficiency benefit?
>y
> 
> Le mar. 29 sept. 2015 à 06:34, Mital Vora  <mailto:mital.d.v...@gmail.com>> a écrit :
> Great job guys !
> 
> On Sep 29, 2015 4:31 AM, "Brent Fulgham"  <mailto:bfulg...@apple.com>> wrote:
> Yes — this is great work!
> 
> We’re still working through a few rough edges, but very soon we can get rid 
> of the whole Windows-specific build cruft, which will be a happy day.
> 
> Thanks,
> 
> -Brent
> 
> > On Sep 28, 2015, at 3:03 PM, Michael Catanzaro  > <mailto:mcatanz...@igalia.com>> wrote:
> >
> > On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
> >> All the Windows buildbots are now using Windows.  We are planning to
> >> leave all the Visual Studio projects in the tree for a couple weeks,
> >
> > Thanks Alex! It sounds like you're planning to remove the Visual Studio
> > projects in a couple weeks, and it's great news that we'll soon be rid
> > of another build system.
> >
> > Michael
> > ___
> > 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

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

Re: [webkit-dev] CMake on Windows

[Brent Fulgham]

Yes — this is great work!

We’re still working through a few rough edges, but very soon we can get rid of 
the whole Windows-specific build cruft, which will be a happy day.

Thanks,

-Brent

> On Sep 28, 2015, at 3:03 PM, Michael Catanzaro  wrote:
> 
> On Mon, 2015-09-28 at 13:28 -0700, Alex Christensen wrote:
>> All the Windows buildbots are now using Windows.  We are planning to
>> leave all the Visual Studio projects in the tree for a couple weeks,
> 
> Thanks Alex! It sounds like you're planning to remove the Visual Studio
> projects in a couple weeks, and it's great news that we'll soon be rid
> of another build system.
> 
> Michael
> ___
> 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] WinCairo Stability

[Brent Fulgham]

Alex Christensen does keep the WinCairo port up and running, and we have a 
build bot that tracks that.

Unfortunately, we don’t have an active WinCairo test bot, so it’s not always 
possible to know when something is broken in a subtle way on that port.

Please let us know what you find out!

Thanks,

-Brent

> On Aug 21, 2015, at 3:54 PM, Vienneau, Christopher  wrote:
> 
> Thanks Darin,
> 
> I've got my release build up now which is sufficient to do some more 
> verification that I wanted to do.  I hadn't known about the build dashboard, 
> that will be a handy tool for me in the future.
> 
> Chris
> 
> -Original Message-
> From: Darin Adler [mailto:da...@apple.com] 
> Sent: Friday, August 21, 2015 3:16 PM
> To: Vienneau, Christopher 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] WinCairo Stability
> 
> These all look like backtraces from assertion failures. If you are working on 
> WebKit, the next step would be to figure out which assertion is failing.
> 
> If you’re looking for greater stability, you could try a release build 
> instead of a debug build, which won’t include the assertions.
> 
> I’m not sure if there’s anyone actively trying to keep the WinCairo port 
> working well. It doesn’t have a build bot on the Dashboard 
> https://build.webkit.org/dashboard/ so I there’s no easy way for WebKit 
> contributors to notice if platform-specific bugs are introduced.
> 
> — 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] Windows Build Now on VS2015

[Brent Fulgham]

Hi Floks,

We’ve finished updating the various Windows builds to VS2015. Full regression 
tests are now completing on these new builds, and seem to be comparable in 
terms of stability and correctness.

Please let me know if you encounter any new issues on Windows. I know that EA 
encountered some JavaScript issues in a prior revision, but I haven’t been able 
to replicate this problem (at least yet).

VS2015 is churning out a number of new build warnings, which I hope to address 
over the coming weeks. It will also likely have some useful static analysis 
results in the Windows-specific portions of the code that we should evaluate.

Thanks,

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

[webkit-dev] Migrating to Visual Studio 2015

[Brent Fulgham]

Hi Everyone,

Now that Visual Studio 2015 Express is available for download, I would like to 
migrate our Windows builds over to the new compiler.

This will allow us to start taking advantage of more C++14 features, as well as 
allowing us to remove a number of workarounds we’ve held in our code base to 
work around compiler errors.

If this poses a problem for anyone currently working on WebKit, please contact 
me so that we can take appropriate steps to avoid any problems.

Thanks,

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

Re: [webkit-dev] border-radius lost when applying -webkit-filter

[Brent Fulgham]

I'll see if I can reproduce this using our Apple Windows port, which also uses 
GraphicsLayerCA, though one based on  Windows graphics primitives.

The WinCairo compositor is based on the OpenGL ES backend, via the ANGLE 
library. Alex Christensen knows more about how that works.

Thanks,

-Brent

Sent from my iPad

> On Jul 30, 2015, at 2:26 PM, Myles C. Maxfield  wrote:
> 
> I'm testing on the Mac OS X port, which uses GraphicsLayerCA.
> 
> Sounds like a bug with whichever compositor the win-cairo port is using, 
> which I am not familiar with.
> 
> --Myles
>> On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher  wrote:
>> 
>> Thanks Myles,
>>  
>> Before I go through the effort of re-integrating, a few questions about your 
>> test:
>>  
>> Which port are you testing on? I had been able to repro in our demo and the 
>> win-cairo demo (both using the 179714 build). 
>> Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
>> that your version is newer than mine, it *might* be why it’s working.
>>  
>> Chris
>>  
>> From: Myles C. Maxfield [mailto:mmaxfi...@apple.com] 
>> Sent: Tuesday, July 28, 2015 5:36 PM
>> To: Vienneau, Christopher
>> Cc: Webkit Development List
>> Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter
>>  
>> This works for me using the latest ToT build. I would recommend updating 
>> your source tree.
>>  
>> --Myles
>> On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher  wrote:
>>  
>> Hi,
>>  
>> I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this 
>> issue where border radius is lost if a css filter is also applied.  My 
>> sample page looks like this:
>> 
>>  
>> 
>> Basic CSS Filters
>> Basic CSS Filters
>>  
>> 
>> #pic {
>>   border-radius: 10px;
>>   -webkit-filter: sepia(0.8);
>> }
>> 
>>  
>> 
>> 
>>   
>> 
>> 
>> 
>>  
>> When I run with the above code the image is rendered with the Sepi filter, 
>> but the border radius is not applied.  If I comment out the filter the image 
>> is properly rendered with the border radius applied.  By debugging I can see 
>> that a different code path is followed in the two cases.  
>> Without the filter:
>> > WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path 
>> > & path, WebCore::WindRule windRule) Line 951C++
>>WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const 
>> WebCore::FloatRoundedRect & rect) Line 586 C++
>>
>> WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
>>  * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect 
>> & clipRect) Line 540  C++
>>WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo 
>> & paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180  C++
>> …
>> we get into clipRoundedInnerRect which goes into the code which can perform 
>> the clipping operation, and all works as expected.
>>  
>> With the Filter (3 callstacks below):
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() Line 1960 
>>C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() Line 595  
>> C++
>>
>> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>>  & layer, WTF::Vector & 
>> childLayersOfEnclosingLayer, int depth) Line 1522 C++
>> …
>>  
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
>> Line 1124   C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
>> C++
>>
>> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>>  & layer, WTF::Vector & 
>> childLayersOfEnclosingLayer, int depth) Line 1609 C++
>> …
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
>> Line 1124   C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
>> C++
>> 
>> WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer
>>  & compositingAncestor, WebCore::RenderLayer & layer, bool 
>> compositedChildrenOnly) Line 1862   C++
>> …
>>  
>> In this path we never call clipRoundedInnerRect, we do however call 
>> setContentsClippingRect with what looks like appropriate parameters to do 
>> what we would want

Re: [webkit-dev] Compilation issue with VS2015RC

[Brent Fulgham]

Hi Chris,

We noticed the same thing. Please see 
, where we are discussing how 
to move forward.

Thanks!

-Brent

> On Jul 10, 2015, at 4:05 PM, Vienneau, Christopher  wrote:
> 
> Hello,
>  
> Recently we’ve been attempting to move our code base to build with VS2015 RC 
> since this provides us with some support that we’ll be needing in the future 
> for our products.  The changes for compilation with the new compiler haven’t 
> been too bad, and I have everything building with the exception of one line:
>  
> FILE: JSCSSValueCustom.cpp
> Line95:
> 67   JSValue toJS(ExecState*, JSDOMGlobalObject* globalObject, 
> CSSValue* value)
> 68   {
> 69   if (!value)
> 70   return jsNull();
> 71   
> 72   // Scripts should only ever see cloned CSSValues, never the 
> internal ones.
> 73   ASSERT(value->isCSSOMSafe());
> 74   
> 75   // If we're here under erroneous circumstances, prefer 
> returning null over a potentially insecure value.
> 76   if (!value->isCSSOMSafe())
> 77   return jsNull();
> 78   
> 79   JSObject* wrapper = getCachedWrapper(globalObject->world(), 
> value);
> 80   
> 81   if (wrapper)
> 82   return wrapper;
> 83   
> 84   if (value->isWebKitCSSTransformValue())
> 85   wrapper = CREATE_DOM_WRAPPER(globalObject, 
> WebKitCSSTransformValue, value);
> 86   else if (value->isWebKitCSSFilterValue())
> 87   wrapper = CREATE_DOM_WRAPPER(globalObject, 
> WebKitCSSFilterValue, value);
> 88   else if (value->isValueList())
> 89   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValueList, 
> value);
> 90   else if (value->isSVGPaint())
> 91   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGPaint, 
> value);
> 92   else if (value->isSVGColor())
> 93   wrapper = CREATE_DOM_WRAPPER(globalObject, SVGColor, 
> value);
> 94   else if (value->isPrimitiveValue())
> 95   wrapper = CREATE_DOM_WRAPPER(globalObject, 
> CSSPrimitiveValue, value);
> 96   else
> 97   wrapper = CREATE_DOM_WRAPPER(globalObject, CSSValue, 
> value);
> 98   
> 99   return wrapper;
> 100 }
>  
> It produces the linker error:
> JSBindingsAllInOne.obj : error LNK2019: unresolved external symbol "public: 
> __thiscall WebCore::CSSPrimitiveValue::operator WebCore::CSSPrimitiveValue> > class WTF::Ref WebCore::CSSPrimitiveValue>(void)const " 
> (??$?BV?$Ref@VCSSPrimitiveValue@WebCore@@@WTF@@@CSSPrimitiveValue@WebCore@@QBE?AV?$Ref@VCSSPrimitiveValue@WebCore@@@WTF@@XZ)
>  referenced in function "class WebCore::JSDOMWrapper * __cdecl 
> WebCore::createWrapper WebCore::CSSPrimitiveValue>(class WebCore::JSDOMGlobalObject *,class 
> WebCore::CSSPrimitiveValue *)" 
> (??$createWrapper@VJSCSSPrimitiveValue@WebCore@@VCSSPrimitiveValue@2@@WebCore@@YAPAVJSDOMWrapper@0@PAVJSDOMGlobalObject@0@PAVCSSPrimitiveValue@0@@Z)
>  
> As you can see there are many other similar code lines in the area, none of 
> which cause a problem.  Despite my many attempts I can’t seem to satisfy the 
> linker by providing it the definition it needs.
> · I’ve attempted manually adding the copy constructor definition (I 
> believe that is what it is describing):
> o   CSSPrimitiveValue::CSSPrimitiveValue(ClassType classType, const 
> CSSPrimitiveValue& cloneFrom)
> o   CSSPrimitiveValue::CSSPrimitiveValue(const CSSPrimitiveValue& cloneFrom)
> · I’ve tried removing the usage of the “AllInOne” file, thinking that 
> it may be causing some issue.
> · I’ve attempted to debug the code when the offending line is 
> commented out, hoping to see better how the other lines function.  Though I’m 
> not sure what path would cause it to execute, I haven’t hit it in my limited 
> testing.
> · One of my colleagues reached out the MS on the issue, but it 
> behaves as expect on their end (small sample code does not find a bug in the 
> compiler). 
> https://social.msdn.microsoft.com/Forums/en-US/6b9787f3-62bd-473a-8aa1-5f6cd85ed87b/breaking-change-in-visual-studio-2015-rc?forum=vcgeneral
>  
> 
>  
>  
> Any suggestions would be much appreciated
>  
> Thanks
>  
> Chris
>  
>  
>  
> ___
> 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

Re: [webkit-dev] Please be careful with webkitpy changes!

[Brent Fulgham]

The Windows EWS bots process patches fairly quickly. Once I corrected the 
problem today, it managed to process about 97 patches in about an hour.

I do think one bottleneck is due to individual EWS bots “locking” patches. The 
first bot to reach a patch locks the patch against other bots handling it. If 
the patch happens to be ‘consumed’ be a bot with some kind of problem (e.g., 
bad local configuration, a full disk drive, etc.), that patch will not be 
touched again — even if the other eight EWS bots are sitting dormant.

Is there some other processing metric you are concerned about?

 Brent Fulgham - Apple Inc.



> On Apr 1, 2015, at 2:26 PM, Maciej Stachowiak  wrote:
> 
> 
> Is it possible to make EWS start processing changes more promptly?
> 
>> On Apr 1, 2015, at 12:42 PM, Brent Fulgham  wrote:
>> 
>> Hi Everyone,
>> 
>> We lost Windows EWS coverage for the past 36 hours due to a very 
>> benign-appearing change to some webkitpy code. I haven’t yet figured out why 
>> this particular set of changes caused the Windows bots to start failing, but 
>> it has to do with various differences between the Cygwin Python 2.7.8 build 
>> and the versions used on our other EWS bots.
>> 
>> This does not seem like something developers SHOULD have to worry about, but 
>> it’s an unfortunately reality that they really do need to.
>> 
>> To make matters worse, the patch that introduced the problem passed EWS. 
>> This is because the EWS bots only really begin using changes to webkitpy 
>> when they restart processing (about once every 10-13 build iterations).
>> 
>> To help combat this problem, I’d like to request that when making changes to 
>> webkitpy, please keep an eye on the various EWS bots to make sure they 
>> continue processing. If they do start failing, please roll the patch back 
>> out and we can work together to resolve the issue.
>> 
>> I apologize for how manual and inconvenient this needs to be (at least for 
>> now), but keeping the EWS up and running is critical to the smooth function 
>> of this project.
>> 
>> If you have any questions, please don’t hesitate to e-mail me or look for me 
>> on IRC.
>> 
>> Thanks!
>> 
>> -Brent
>> ___
>> 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

[webkit-dev] Please be careful with webkitpy changes!

[Brent Fulgham]

Hi Everyone,

We lost Windows EWS coverage for the past 36 hours due to a very 
benign-appearing change to some webkitpy code. I haven’t yet figured out why 
this particular set of changes caused the Windows bots to start failing, but it 
has to do with various differences between the Cygwin Python 2.7.8 build and 
the versions used on our other EWS bots.

This does not seem like something developers SHOULD have to worry about, but 
it’s an unfortunately reality that they really do need to.

To make matters worse, the patch that introduced the problem passed EWS. This 
is because the EWS bots only really begin using changes to webkitpy when they 
restart processing (about once every 10-13 build iterations).

To help combat this problem, I’d like to request that when making changes to 
webkitpy, please keep an eye on the various EWS bots to make sure they continue 
processing. If they do start failing, please roll the patch back out and we can 
work together to resolve the issue.

I apologize for how manual and inconvenient this needs to be (at least for 
now), but keeping the EWS up and running is critical to the smooth function of 
this project.

If you have any questions, please don’t hesitate to e-mail me or look for me on 
IRC.

Thanks!

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

Re: [webkit-dev] Modern image formats for WebKit

[Brent Fulgham]

> On Mar 20, 2015, at 2:39 PM, Darin Adler  wrote:
> 
> Dave Hyatt originally created this when we first were planning the Apple 
> Windows port of WebKit, but in the end we chose to not use them for the 
> Windows port. They aren’t used in the Windows port nor in the Mac or iOS 
> ports; for all of those we use a separate image decoding library.
> 
> So this is a really a question for people working on other active ports like 
> the EFL and GTK ones. Are there other libraries that you could use for image 
> decoding, or do you still want to keep and maintain a WebKit copy of these 
> image decoders?

The WinCairo and GTK ports definitely use these image decoders. I think the EFL 
port does as well, but I’m not sure.

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

Re: [webkit-dev] WorkQueue for Windows?

[Brent Fulgham]

Hi Antti,

Take a look at . I haven't 
landed this yet, because I was hoping to get some kind of test for this. 
However, it seems to introduce no problems, so we could go ahead and land it.

Question: why do we have a separate WorkQueue implementation in DumpRenderTree 
*and* WebKitTestRunner? Seems like we could do some consolidation...

-Brent


> On Mar 6, 2015, at 10:55 AM, Anders Carlsson  wrote:
> 
> I think we used to have a WorkQueue implementation for Windows WK2 - anyone 
> should be able to dig it up.
> 
> (Alternatively, we can just make an implementation using std::thread).
> 
> - Anders
> 
>> On Mar 6, 2015, at 10:46 AM, Antti Koivisto  wrote:
>> 
>> Hi,
>> 
>> I'd like to start using WTF::WorkQueue abstraction in WebCore code. However 
>> we are currently missing a Windows implementation (WorkQueue used to be part 
>> of WK2). Anyone interested in making one? I assume it wouldn't be a 
>> difficult task for someone who knows the platform.
>> 
>> 
>>   antti
>> ___
>> 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] Remove CSS_IMAGE_ORIENTATION Feature Guard

[Brent Fulgham]

Hi Gyuyoung,

Since you completed work on Bug 92330, I think we now do wish to keep the 
ENABLE_CSS_IMAGE_ORIENTATION Flag.

Can you please confirm?

Thanks,

-Brent

> On Jul 2, 2013, at 6:00 PM, Gyuyoung Kim  wrote:
> 
> Hi Brent,
> 
> Sorry for no activity on this. This work was pushed back on the my priority 
> list. Thus, I agree to remove this feature if nobody(including me) submits 
> meaningful patch until July 17th.
> 
> Gyuyoung. 
> 
> 
> On Wed, Jul 3, 2013 at 3:05 AM, Brent Fulgham  <mailto:bfulg...@apple.com>> wrote:
> Hi Everyone,
> 
> I haven't seen any action on https://bugs.webkit.org/show_bug.cgi?id=116555 
> <https://bugs.webkit.org/show_bug.cgi?id=116555> (or 
> https://bugs.webkit.org/show_bug.cgi?id=92330 
> <https://bugs.webkit.org/show_bug.cgi?id=92330>) in the past month.
> 
> I'd like to remove this logic unless there is some activity here.  We can 
> always add it back in from SVN history if someone does want to work on it.
> 
> I'll submit a patch to remove this code on July 17th unless something changes.
> 
> Thanks,
> 
> -Brent
> 
> 
> 
> On Jun 4, 2013, at 10:15 PM, Gyuyoung Kim wrote:
> 
>> Hi,
>> 
>> I'm interested in this feature. So, I took Bug 92330 over. Though I rebased 
>> the feature according to review comments, this feature doesn't work yet. So, 
>> I have investigated why it doesn't work. However, unfortunately, I need to 
>> have time a little further. If there is no big reason this patch should be 
>> removed, I'd like to support this feature.
>> 
>> Gyuyoung.
>> On Jun 5, 2013 9:45 AM, "Mike Lawther" > <mailto:mikelawt...@google.com>> wrote:
>> Fwiw, the original author is no longer working on Blink, and the code has 
>> been removed from there.
>> 
>> mike
>> 
>> On Jun 5, 2013 1:24 AM, "Brent Fulgham" > wrote:
>> We have code in WebKit that is protected by the 
>> ENABLE(CSS_IMAGE_ORIENTATION) guard, but no active WebKit ports seem to 
>> enable this feature.
>> 
>> Is anyone currently working on (or planning to work on) this feature?
>> 
>> Since this CSS feature is currently in an early draft form, and is likely to 
>> change, we may not want to retain this dead code as it will most likely 
>> become obsolete very quickly.
>> 
>> If no one wants to claim ownership of this feature in the next few days, I 
>> will submit a patch to remove the dead code.
>> 
>> Thanks,
>> 
>> -Brent
>> ___
>> 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 <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

[webkit-dev] Windows Bots Are Green!

[Brent Fulgham]

Hi Everyone,

Over the past few weeks I’ve spent a considerable amount of time reviewing and 
correcting a number of problems with the Windows testing infrastructure.

We were skipping thousands of tests, including Accessibility, http tests, and 
large sections of forms, css, and svg tests. Some tests were skipped because 
features were supposedly incomplete, but in the years since the skip entry was 
added to the file, the work had been completed and feature worked perfectly 
well. Some tests were skipped simply because feature flags had never been 
enabled on Windows.

Happily, all of this is in the past. Now that this work is complete, we have 
much more test coverage of many areas of WebKit that had been previously 
ignored on this platform.

1. We are now using native Windows Apache to run our HTTP tests, and have been 
doing so for the past couple of weeks. This seems to be quite stable, and is 
allowing us to make sure SSL and other important features work properly on 
Windows.
2. Accessibility tests are back up and running.
3. Thanks to Ossy, we now run all JSC stress tests on Windows.
4. Nearly all other tests are now running, with a few notable exceptions below.
5. I have switched to running Windows tests in a single process, because I 
found that running in parallel introduced inconsistent results. (See 
>).

So now that I’ve completed this task, PLEASE help keep the Windows bots green! 
:-)

If you are at all interested in the various Windows ports, and are looking for 
something to do, there are a number of bugs I’ve filed that could use some 
attention:

1. For some reason, running layout tests in parallel introduces inconsistent 
behavior and spurious failures. There must be some kind of cross-talk between 
the different shards. >.
2. There are a number of debug assertions firing that cause Debug test runs to 
exit early. (see >, 
3. Something weird is going on with the page cache. 
>
4. Accessibility tests have a number of problems:
(a) Several Accessibility tests fail in debug mode because they assert that 
they are accessing text iterators before layout is complete. The comment with 
this assertion indicates that this can cause crashes and instability. 
>
(b) Some accessibility tests are very flaky with regard to digging down into 
the DOM. Test will pass one run, fail the next. 
>

Feel free to contact me any time if you want to tackle any of these problems!

Otherwise, please just help keep the Windows bots green. I don’t want to have 
to go through all of this again! :-)

Best regards,

-Brent


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

[webkit-dev] WinCairo 64-bit Bot Failures

[Brent Fulgham]

Hi Everyone,

It looks like the WinCairo 64-bit bot is having some trouble due to the dread 
Cygwin rebaseline requirement:

Could someone with bot access please take the bot down and rebaseline it?

These (annoying) failures are one of the reasons I’ve been trying to get the 
build to work outside of Cygwin. (Patches welcome!)

Thanks,

-Brent
3>-- Build started: Project: JavaScriptCoreGenerated, Configuration: 
Release_WinCairo Win32 --
3>  /usr/bin/bash
3>  touch "%ConfigurationBuildDir%\buildfailed"
3>  perl build-generated-files.pl "%ConfigurationBuildDir%" 
"C:\cygwin\home\webkitbot\win-cairo-release\build\WebKitLibraries\win" 
"%PlatformArchitecture%"
3>  echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Page.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Runtime.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Timeline.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Worker.json
 ' | cmp -s - EnabledInspectorDomains || echo 
'/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/ApplicationCache.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/CSS.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Console.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOM.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMDebugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/DOMStorage.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Database.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Debugger.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/GenericTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Inspector.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/LayerTree.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Network.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/OverlayTypes.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Page.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Runtime.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Timeline.json
 
/home/webkitbot/win-cairo-release/build/Source/JavaScriptCore/inspector/protocol/Worker.json
 ' > EnabledInspectorDomains
3>0 [main] sh 3272 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x3D)
3>  /bin/sh: fork: retry: Resource temporarily unavailable
3>0 [main] sh 2024 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x33)
3>  /bin/sh: fork: retry: Resource temporarily unavailable
3>0 [main] sh 2072 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x3C)
3>  /bin/sh: fork: retry: Resource temporarily unavailable
3>0 [main] sh 2084 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded to different address: parent(0x2C) 
!= child(0x33)
3>  /bin/sh: fork: retry: Resource temporarily unavailable
3>0 [main] sh 3528 child_info_fork::abort: 
C:\cygwin\bin\cygreadline7.dll: Loaded

Re: [webkit-dev] Abandoned Tests

[Brent Fulgham]

Oh! Sorry. All of these tests fail.

They fail because none of the ports actually implement the features they test:

1. fast/dom/title-directionalty and 
fast/dom/title-directionality-removeChild.html:

These test that  supports a ‘dir’ property. We don’t, so they all fail.

2. fast/events/drag-image-filename.html:

These expect DRT/WKTR to support ‘dumpFilenameBeingDragged’, which might be a 
useful debugging method.

3. fast/autoresize:

These expect the system to support something called “enableAutoResizeMode(x, y, 
width, height)”. I’m not sure exactly what it’s supposed to do.

4. fast/overflow/scrollbar-restored-and-then-locked.html

These expect DRT/WKTR to support “setScrollbarPolicy”, which seems to allow you 
to force a scrollbar (horizontal or vertical) to be on or off. Perhaps this
would be a useful thing to have for testing.

Thanks,

-Brent

> On Jan 22, 2015, at 6:41 AM, Myles C. Maxfield  wrote:
> 
> That's what I mean. What happens when we actually run them?
> 
>> On Jan 21, 2015, at 9:29 PM, Brent Fulgham  wrote:
>> 
>> Hi Myles,
>> 
>> These tests don’t fail — they are all skipped on mac, win, gtk, and efl.
>> 
>> -Brent
>> 
>>> On Jan 21, 2015, at 9:24 PM, Myles C. Maxfield  wrote:
>>> 
>>> On which platforms do they fail?
>>> 
>>> —Myles
>>>> On Jan 21, 2015, at 8:48 PM, Brent Fulgham  wrote:
>>>> 
>>>> I’ve been reviewing the various Windows layout tests, and have run across 
>>>> a few tests that seem to be leftovers from the Chromium project. I think 
>>>> all ports currently skip these tests:
>>>> 
>>>> 1. fast/dom/title-directionality-removeChild.html
>>>> 2. fast/dom/title-directionality.html
>>>> 3. fast/events/drag-image-filename.html
>>>> 4. fast/autoresize
>>>> 5. fast/overflow/scrollbar-restored-and-then-locked.html
>>>> 
>>>> If no one is using these tests, or plans to, I would like to remove them 
>>>> and the disconnected bits of code in DRT/WKTR that were originally meant 
>>>> to drive this code.
>>>> 
>>>> If I don’t hear anything by this time next week, I’ll remove the code.
>>>> 
>>>> Thanks,
>>>> 
>>>> -Brent
>>>> ___
>>>> 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] Abandoned Tests

[Brent Fulgham]

Hi Myles,

These tests don’t fail — they are all skipped on mac, win, gtk, and efl.

-Brent

> On Jan 21, 2015, at 9:24 PM, Myles C. Maxfield  wrote:
> 
> On which platforms do they fail?
> 
> —Myles
>> On Jan 21, 2015, at 8:48 PM, Brent Fulgham  wrote:
>> 
>> I’ve been reviewing the various Windows layout tests, and have run across a 
>> few tests that seem to be leftovers from the Chromium project. I think all 
>> ports currently skip these tests:
>> 
>> 1. fast/dom/title-directionality-removeChild.html
>> 2. fast/dom/title-directionality.html
>> 3. fast/events/drag-image-filename.html
>> 4. fast/autoresize
>> 5. fast/overflow/scrollbar-restored-and-then-locked.html
>> 
>> If no one is using these tests, or plans to, I would like to remove them and 
>> the disconnected bits of code in DRT/WKTR that were originally meant to 
>> drive this code.
>> 
>> If I don’t hear anything by this time next week, I’ll remove the code.
>> 
>> Thanks,
>> 
>> -Brent
>> ___
>> 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] Abandoned Tests

[Brent Fulgham]

I’ve been reviewing the various Windows layout tests, and have run across a few 
tests that seem to be leftovers from the Chromium project. I think all ports 
currently skip these tests:

1. fast/dom/title-directionality-removeChild.html
2. fast/dom/title-directionality.html
3. fast/events/drag-image-filename.html
4. fast/autoresize
5. fast/overflow/scrollbar-restored-and-then-locked.html

If no one is using these tests, or plans to, I would like to remove them and 
the disconnected bits of code in DRT/WKTR that were originally meant to drive 
this code.

If I don’t hear anything by this time next week, I’ll remove the code.

Thanks,

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

Re: [webkit-dev] Disk cache

[Brent Fulgham]

I wonder if we could easily modify the Windows port to make use of a Network 
process.

-Brent

> On Nov 3, 2014, at 8:07 AM, Anders Carlsson  > wrote:
> 
> 
>> On Nov 3, 2014, at 12:22 AM, Benjamin Poulain > > wrote:
> 
>> I believe it would be better to enable the network process for all process 
>> models. Maintaining multiple configurations for marginal gains is not 
>> sustainable, especially in the network stack.
> 
> I agree 100%. Not to mention that we also want to get rid of the “single web 
> process” code path, and just make it a special case of having multiple web 
> processes with a maximum process cap of 1.
> 
> - Anders
> 
> ___
> 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] Fwd: Planning on Requiring Python 2.7 Soon

[Brent Fulgham]

Hi Everyone,

This is just a reminder that I plan on making source updates on Wednesday that 
will require Python 2.7 for our test system. So far, it sounds like this will 
not be a problem for anyone, but please let me know if this will be a 
significant issue for you.

Thanks,

-Brent

> Begin forwarded message:
> 
> From: Brent Fulgham 
> Date: September 10, 2014 at 4:31:05 PM PDT
> To: webkit-dev 
> Subject: [webkit-dev] Planning on Requiring Python 2.7 Soon
> 
> Hi Everyone,
> 
> Now that I’ve worked through the minor issues that prevented us from using 
> Python 2.7 on our Windows bots, I’d like to move the goalposts and require 
> Python 2.7 (or newer) for our build and test machines.
> 
> Will this cause anyone any problems if this becomes the new law of the land?
> 
> I plan on making this change on September 17th if I do not hear from anyone 
> on this topic.
> 
> Thanks!
> 
> -Brent
> ___
> 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] Planning on Requiring Python 2.7 Soon

[Brent Fulgham]

Hi Everyone,

Now that I’ve worked through the minor issues that prevented us from using 
Python 2.7 on our Windows bots, I’d like to move the goalposts and require 
Python 2.7 (or newer) for our build and test machines.

Will this cause anyone any problems if this becomes the new law of the land?

I plan on making this change on September 17th if I do not hear from anyone on 
this topic.

Thanks!

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

[webkit-dev] Windows (Temporary) Build Turmoil

[Brent Fulgham]

If you don’t care about building WebKit on Windows, you can stop reading now!

Still here?  Okay:

I’m attempting to make the Windows build rely less on the Cygwin tool chain. 
There are a number of reasons for this, but one of the major benefits I hope to 
derive is to reduce the amount of effort required to successfully build WebKit 
on Windows.

In service of that goal, I am actually making things slightly more complicated: 
you now need to install a Windows build of Perl and Python, You can use 
ActiveState’s builds (http://downloads.activestate.com), or the ‘official’ 
Windows ports of these products.

If you encounter any problems with this “dual Perl/dual Python” situation, 
please let me know and I’ll work to resolve whatever difficulty you encounter. 
However, based on my testing on our internal build machines I do not anticipate 
you will have any trouble.

Thanks,

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

Re: [webkit-dev] help: HTML5 video Overlay with accelerated composition

[Brent Fulgham]

Can you provide specifics about your test case?

1. Are you using WebKit QT, or something else?
2. Can you provide an example showing what you are trying to do?

Thanks,

-Brent

> On May 29, 2014, at 4:11 AM, T andolsi  wrote:
> 
> Hi,
> 
> 
> Triying to use overlay for Video enabling the accelerated composition,
> I see that the graphic is always on top of the video, and video is not
> visible.
> 
> The backroung RenderLayer is always on top if the Video Render Layer.
> 
> Is it possible to use Overlay for HTML5 video support with accelerated
> composition?
> 
> 
> Regards,
> Thouraya.
> ___
> 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] Another Update: Cygwin Recommendations for Windows Builders

[Brent Fulgham]

A couple of weeks ago I reported a problem I noticed with Python 2.7 in our 
Cygwin-based builds:

> 2. Python version 2.6.8:  If not, you get errors indicating “Invalid Python 
> installation: unable to open 
> ‘/cygdrive/c/Cygwin/include/python2.7/pyconfig.h”. This seems to be a 
> regression since 2.6.8. Again, Cygwin tries to upgrade you to 2.7.3 every 
> time you run the Cygwin setup utility. You must manually specify that you 
> want 2.6.8.


I tracked down the cause of this issue (see 
https://bugs.webkit.org/show_bug.cgi?id=132023 if you are curious), and have 
updated our builders to use Python 2.7.

If you update to ToT WebKit, you should be able to safely build and run with 
Python 2.7.

I have also removed the warning in update-webkit that would complain about 
Python 2.7 when you attempted to get updated sources.

Please let me know if you encounter any problems with this new environment.

Thanks,

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

Re: [webkit-dev] Problems building JavaScriptCore/WebKit for Windows desktop

[Brent Fulgham]

Hi Eric,

I’m sorry you encountered problems building WebKit. I’ve interleaved some 
responses below.

On Apr 1, 2014, at 4:34 AM, Eric Wing  wrote:

> I am trying to build JavaScriptCore for Windows desktop. (Ultimately,
> I just want a x86_64 .lib and .dll I can link against for Win 7 and 8.
> I would be happy not building it and just downloading the pre-build
> binaries somewhere if that's an option.)

You might want to take a look at dim3 . 
Brian Barnes has been generating JSC builds from time-to-time for use in his 
game engine.

> - The cygwin-downloader instructions about installing from the Local
> Directory doesn't seem to work. When it is time to hit 'Next' in the
> select the packages screen, it seems that the packages are not
> detected. This results in nothing getting installed. My attempts to
> force it to detect and install have failed.

As far as I know, this works. Please file a bug at  
with log output if you are seeing problems.

>   - The python version it picks by default is 2.7.x and Webkit
> complains it needs 2.6.x so I have to force a downgrade.

Yes. This is extremely annoying, but Cygwin has not released a 32-bit Python 
that works.

>   - The curl or ssl package has some kind of bug and either requires a
> downgrade of one of the packages or a change to the
> update-webkit-dependency script to use tlsv1 instead of sslv3

This is a known issue with cURL 7.34.0, which I documented separately. This has 
been fixed by the cURL project, but I have not seen a Cygwin update with the 
fixes.

>   - There is a missing instruction that C:\cygwin\bin must be added to
> the Windows %PATH%, otherwise a bunch of "/usr/bin/which bash"
> commands fail (because it can't find bash)

I’m surprised by this. The CMD files that emit this error message should be 
setup to ignore it. If it cannot find bash, it updates the PATH with the Cygwin 
path. So, I suspect that those messages are simply warnings to you, not actual 
errors that block the build. If they are terminating your build, please file a 
bug and attach logging output.

>   - I get a warning about having svn 1.8.8 when 1.7.10 is the supported 
> one

Yes. I discussed this issue separately.

> - The php instructions to install php don't work. I think a link is broken.

Can you file a bug with the error you are seeing?

> - Running update-webkit causes me problems with Git (it just hangs) so
> I went to the SVN source ball.

I think I ran into this error myself several months ago when I accidentally put 
a git checkout somewhere inside my svn repository. If you continue to see a 
problem with this, please file a bug.

> - update-webkit reports after the SVN 1.8.8 warning with 2 instances
> of "Error (2): The system cannot find the file specified." I don't
> know what it's complaining about. It goes on to tell me I don't have
> the Mozilla Math fonts. (I think those links may be stale.) But
> finally it says "Installed tools are correct for the Webkit build”

The ‘cannot find the file specified’ are checks for installed MathML fonts. You 
need these for testing (and to get good MathML rendering in WinLauncher), but 
they are not needed to build. You can ignore these messages.

> Using the latest version (Monday) with Visual Studio 2013, I think
> there are some new bugs in the code base. The build now expects Core
> Foundation to be available on Windows to build WTF. This was not the
> case before and I think this is a new bug. This propagates down to
> SchedulePair.h which doesn't seem to have any non-Core Foundation
> path. (I expect this will be a problem speaking from my Android work.)

Both the Apple Windows and WinCairo ports use (a form of) CoreFoundation. 
WinCairo uses the ‘OpenCFLite” version of CoreFoundation. You need this support 
library to build WebKit and JSC, as documented on our website.

> One of the prior versions was failing on ruby related stuff or could
> not find files. I'm not fuzzy on the details because I've tried way
> too many things.

I’m sorry you encountered problems, but its very difficult to make suggestions 
without some details. Could you please file bugs about what you’ve encountered?

Good luck!

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

[webkit-dev] Update: Cygwin Recommendations for Windows Builders

[Brent Fulgham]

Hi folks,

Yesterday I documented a few problems I was having with Cygwin, and asked if 
anyone else was encountering any issues. Since then, I’ve figured out what was 
going on, and I wanted to post a follow-up to document my findings. I’ll also 
be updating our Wiki page on the topic 
().

1. Curl version 7.34.0 has a known bug that prevents it from authenticating 
over SSL. This means that ‘update-webkit’ will fail when attempting to sync 
with our servers at apple.com.  Please be sure to use cURL 7.33.0 (and make 
sure libcurl is the matching version).  See 
 for details.
Note: This has already been fixed by the cURL team, and we just need to 
wait for the Cygwin folks to update their builds.

2. Subversion 1.8 refuses to handshake with our servers at apple.com. I’m 
working with the right folks internally to fix this, at which point we can 
allow svn 1.8 clients. For now, we need to stick to Svn 1.7.

3. My initial concerns about Make 4.0 were unfounded. After trying the version 
I did not find there to be any issues.

The only significant issue I currently have is with Python 2.7.3. I’ll report 
back once I understand how to resolve this problem.

I have confirmed that if you stick to the above versions of software, you can 
successfully configure and run a Windows build environment. If any of you have 
encountered other problems, please let me know.

Thanks,

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

[webkit-dev] Increasing Finickiness of Cygwin Installations

[Brent Fulgham]

Hi everyone,

I’ve been reviewing some of the setup and reliability problems with our Windows 
builders, and have discovered that there are a number of challenges to getting 
a working Cygwin environment for building WebKit:

You must use very specific versions of some Cygwin tools:

1. curl version 7.33.0:  If not, you get certificate errors when attempting to 
retrieve WebKitAuxilliaryLibraries.zip from apple.com.  Cygwin attempts to 
install 7.34.0, which will cause failures during “update-webkit”.  You must 
manually select the 7.33 build.
2. Python version 2.6.8:  If not, you get errors indicating “Invalid Python 
installation: unable to open ‘/cygdrive/c/Cygwin/include/python2.7/pyconfig.h”. 
This seems to be a regression since 2.6.8. Again, Cygwin tries to upgrade you 
to 2.7.3 every time you run the Cygwin setup utility. You must manually specify 
that you want 2.6.8.
3. Subversion 1.7: If not, you get errors updating sources due to incompatible 
authentication with svn.webkit.org.

I also noticed that Cygwin tried to update to GNU Make 4.0; I left it at 
3.82.90 since our Mac builders use 3.81 and I wanted to avoid yet another 
possible difference.

I experimented with using the 64-bit Cygwin installation, but found that their 
build of bison failed to process our CSSGrammar.y file (exiting with error 141 
without doing anything). The 32-bit build of bison does not share this problem.

While there is a significant benefit to sharing the various build scripts and 
setup routines with our UNIX-flavored ports, I’m growing increasingly concerned 
that relying on Cygwin to provide similar benefits on Windows may become more 
difficult.

I would love to move our Python requirement to 2.7 to be more consistent with 
our Mac builders, but have not found a suitable workaround. Are any other 
WebKit people aware of this problem or solutions for Cygwin?

Thanks,

-Brent

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

Re: [webkit-dev] DerivedSources.make: Another try?

[Brent Fulgham]

Hi All,

I’m arriving to this conversation a bit late, but had a few comments:

On Mar 16, 2014, at 11:06 AM, Patrick Gansterer  wrote:

> DerivedSources.make depends heavily on UNIX command line tools (cat, sed, 
> sort, ...) which are not part of a clean Windows installation and don't 
> provide Windows like installers.
> The point is if we want to make cygwin (with all of its pro and cons) a 
> requirement. At the moment the minimal requirements for building on Windows 
> are GNU Win32 GPerf, Win flex-bision, Perl, Python and Ruby (which provide 
> nice native Windows installers).
> Bugs like 48166 suggest that also not all Apple folks are happy with cygwin.

To paraphrase Churchill, Cygwin is the worst form of UNIX abstraction, except 
for all the others. We find that it is a whole lot easier to get a Windows 
build system up and running using Cygwin than trying to piece together a set of 
disparate GNU tools built and hosted by different parties.

I would not want to move from a system where I can direct people to download 
and run our Cygwin installer, to one where I have to point out a dozen 
different GNU Win32 packages to manually install and setup.

I would be much more interested in a system where we did not need these 
external tools. For example, driving the entire build system through just CMake 
with Perl or Python (or Ruby) would be interesting.

Unfortunately, we still have strong need for a number of UNIX-y tools, such as 
Flex, Bison, and GPerf. This is a common problem for all projects I am aware of 
that involve language implementations.

So I’m not sure that jettisoning Cygwin is a likely outcome at present.

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

Re: [webkit-dev] Error while building webkit on windows

[Brent Fulgham]

Hi,

The problem is with the processing of the CSSGrammar.y file.

On Mar 5, 2014, at 1:52 AM, Baskar CV  wrote:

> 10>  ./CSSGrammar.y:62.1: error: syntax error, unexpected end of file
> 10>  open3: exec of /usr/bin/gcc -E -P -x c++ -DENABLE_3D_RENDERING 
> -DENABLE_CHANNEL_MESSAGING -DENABLE_CSS_BOX_DECORATION_BREAK 
> -DENABLE_CSS_FILTERS -DENABLE_CSS_IMAGE_SET -DENABLE_CSS_REGIONS 
> -DENABLE_CSS_SHAPES -DENABLE_CSS_SHAPE_INSIDE -DENABLE_CSS_STICKY_POSITION 
> -DENABLE_CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED 
> -DENABLE_DETAILS_ELEMENT -DENABLE_FILTERS -DENABLE_FULLSCREEN_API 
> -DENABLE_GEOLOCATION -DENABLE_HIGH_DPI_CANVAS -DENABLE_ICONDATABASE 
> -DENABLE_LEGACY_CSS_VENDOR_PREFIXES -DENABLE_MATHML 
> -DENABLE_MEDIA_CONTROLS_SCRIPT -DENABLE_MEDIA_STATISTICS 
> -DENABLE_METER_ELEMENT -DENABLE_PAGE_VISIBILITY_API -DENABLE_PROMISES 
> -DENABLE_REQUEST_ANIMATION_FRAME -DENABLE_SHARED_WORKERS 
> -DENABLE_SQL_DATABASE -DENABLE_SUBPIXEL_LAYOUT -DENABLE_SVG 
> -DENABLE_SVG_FONTS -DENABLE_TEMPLATE_ELEMENT -DENABLE_VIDEO 
> -DENABLE_VIDEO_TRACK -DENABLE_VIEW_MODE_CSS_MEDIA -DENABLE_WEB_SOCKETS 
> -DENABLE_XHR_TIMEOUT -DENABLE_XSLT /webkit/Source/WebCore/css/CSSGrammar.y.in 
> failed at /webkit/Source/WebCore/bindings/scripts/preprocessor.pm line 81
> 10>  ...propagated at /webkit/Source/WebCore/css/makegrammar.pl line 84.
> 10>  /webkit/Source/WebCore/DerivedSources.make:842: recipe for target 
> 'CSSGrammar.cpp' failed
> 10>  make: *** [CSSGrammar.cpp] Error 2
> 10>  make: *** Waiting for unfinished jobs
> 10>  CSSPropertyNames.gperf: No keywords in input file!
> 10>  calling gperf failed: 256 at /webkit/Source/WebCore/css/makeprop.pl line 
> 306.
> 10>  /webkit/Source/WebCore/DerivedSources.make:785: recipe for target 
> 'CSSPropertyNames.h' failed
> 10>  make: *** [CSSPropertyNames.h] Error 1

Things to check:

1. Is CSSGrammar.y complete? Make sure the checkout didn’t get messed up in 
some fashion.
2. Do you have gperf, flex, and bison installed?  You need flex/bison to 
process the grammar file and turn it into the stub implementation.

> 10>  CSSPropertyNames.gperf: No keywords in input file!

This makes me think that you do NOT have gperf installed. Did you use our 
Cygwin installer package? Or are you using your own local install?

If you are using your own install from the Cygwin website, you should use the 
Setup.exe utility and make sure that flex, bison, and gperf are installed.

Thanks,

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

Re: [webkit-dev] Ports relying on ICU with features omitted?

[Brent Fulgham]

Hi Darin,

On Feb 10, 2014, at 9:40 AM, Darin Adler  wrote:

> I’d like to find out which ports are relying on WebKit support for ICU 
> without certain key features. Maintaining these extra code paths creates some 
> difficulties, and it would be helpful to remove them once no one is relying 
> them. For example, we have support for:
> 
> […]

> I know this is not needed for PLATFORM(MAC), PLATFORM(IOS), and PLATFORM(WIN).
> 
> So I guess I am looking for an answer for PLATFORM(GTK) and PLATFORM(EFL) and 
> any others I might have forgotten to ask about.

I believe that the dim3 game engine (http://www.klinksoftware.net) uses 
JavaScriptCore with a custom ICU. I don’t remember what ICU features they 
exclude, but they might be impacted by this change.

I suspect they could follow WinCE’s approach if this was a significant problem 
for them.

Thanks,

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

Re: [webkit-dev] WebGL backends

[Brent Fulgham]

Hi Dean,

The WinCairo port uses the ANGLE library (and therefore, the “OpenGL” 
machinery) to do WebGL.

I’m pretty sure the GTK+ port uses OpenGL directly, but Martin Robinson can 
probably confirm that.

I think that only really leaves EFL, which may be using OpenGLES?  I’m not sure.

-Brent


On Feb 9, 2014, at 12:59 PM, Dean Jackson  wrote:

> Hi floks.
> 
> I’m looking into simplifying our WebGL code, particularly our 
> GraphicsContext3D implementations. Apple uses either the OS X or iOS OpenGL 
> backend for its ports, but it isn’t clear to me what backend the other ports 
> are using.
> 
> Could the other port developers please reply to let me know how you’re 
> accessing OpenGL?
> 
> Thanks,
> 
> Dean
> 
> ___
> 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] Make accelerated compositing mandatory

[Brent Fulgham]

The same is true for the WinCairo port, though I know Alex Christensen has been 
working towards correcting that.

-Brent

On Jan 28, 2014, at 7:49 AM, Martin Robinson  wrote:

> On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur  wrote:
>> Do you happen to know if we still have ports that build WebKit without
>> accelerated compositing? If not, I'd like to write a patch that removes the
>> flag and makes AC mandatory.
>> 
>> From IRC, I've heard that the Haiku port (not upstreamed) disables the AC
>> flag, but they agree they should switch it on in the future.
> 
> Yes, GTK+ on Windows does not use accelerated compositing. I'm also
> fairly certain the WinCE port does not enable accelerated compositing.
> 
> --Martin
> ___
> 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] Make accelerated compositing mandatory

[Brent Fulgham]

The same is true for the WinCairo port, though I know Alex Christensen has been 
working towards correcting that.

-Brent

On Jan 28, 2014, at 7:49 AM, Martin Robinson  wrote:

> On Tue, Jan 28, 2014 at 2:05 AM, Andrei Bucur  wrote:
>> Do you happen to know if we still have ports that build WebKit without
>> accelerated compositing? If not, I'd like to write a patch that removes the
>> flag and makes AC mandatory.
>> 
>> From IRC, I've heard that the Haiku port (not upstreamed) disables the AC
>> flag, but they agree they should switch it on in the future.
> 
> Yes, GTK+ on Windows does not use accelerated compositing. I'm also
> fairly certain the WinCE port does not enable accelerated compositing.
> 
> --Martin
> ___
> 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] Apple Mac EWS 10.9 upgrade?

[Brent Fulgham]

Hi,

On Jan 6, 2014, at 1:53 PM, Alexey Proskuryakov  wrote:
> 06 янв. 2014 г., в 12:51, Lucas Forschler  написал(а):
> 
>> The Apple Mac EWS bots are currently running 10.8.5.
>> I would like to see if there is any opposition (or support) for upgrading 
>> them to 10.9 / Mavericks.
> 
> Mavericks bots are substantially less reliable at this point, so this will 
> degrade EWS performance. E.g. Mavericks WK2 Release was completely 
> dysfunctional for two days recently for unclear reasons.

This is troubling. Why are they less reliable?

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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

Hi Alex,

> On Jan 4, 2014, at 12:01 PM, Alex Christensen  
> wrote:
> 
> [...]  but I like to err on the more explicit side of coding. It is hard to 
> say "does this make the code cleaner more than it removes useful 
> information?" or "will this cause problems for other developers?" with a 
> style guideline.  

The problem is that those declarations aren't really doing what you think they 
are; we are simply engaging in 'type theater'. 

The annotations indicate what the author thought the resulting type of the RHS 
expression would be, or perhaps were at one time. But they are only showing 
what we are asking the compiler to coerce the result into. I would argue that 
the number of times we really want to coerce the result of an expression to 
something new are relatively rare, and could be handled be the new 'type' 
syntax, or explicit cast declarations.

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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

Hi antti,

On Jan 3, 2014, at 4:12 AM, Antti Koivisto  wrote:

> If we start making rules I'd add the following:
> 
> - Use "auto" when the type name is already mentioned on a line:

+1

> - Use "auto" when the type is irrelevant. This covers things like iterators 
> and adapter classes:

+1

> - Use "auto" when type is obvious for people with basic familiarity with a 
> subsystem:
> 
> auto& style = renderer.style();

I think this is the crux of the argument against using ‘auto’.  Few of us are 
experts in all parts of the system, so it’s not clear why type is returned here.

My personal preference is to use auto, and rely on the IDE to show me what the 
actual type is when I view the code.

However, this does not work well when using our code review tools, since there 
is no ‘type overlay’ available to show us what specific type is being used in 
this case. So I can understand the argument against using ‘auto’ in this 
circumstance.

-Brent



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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

Hi Filip,

Coming back to your earlier example:

> auto newSize = optimalSize();
> vs:
> CGSize newSize = optimalSize();

If I understand your argument, you feel that the explicit CGSize declaration 
helps the reader because it makes the return value of optimalSize() explicit.

However, that declaration is only stating the type that the author *thinks* 
optimalSize() returns.  There is nothing to guarantee that optimalSize() 
returns a CGSize; only that it returns something that the compiler can turn 
into a CGSize through some set of casts.

The code stating CGSize could have been correct at one point, but the return 
type of optimalSize might have been changed to some similar type without anyone 
noticing.

Using ‘auto’ doesn’t seem to make this situation any worse.

In fact, although Sutter’s suggestion of:

auto newSize = CGSize { optimalSize(); }

looks gross to my eye, it might be a useful approach because it would force the 
compiler to complain if we were returning something that was not explicitely a 
CGSize type.

-Brent


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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

Hi Adam,

On Jan 2, 2014, at 2:08 PM, Adam Roben  wrote:

> I found 
> http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> very persuasive in my thinking about when to use auto.

I think this does a much better job of explaining the benefits of ‘auto’ than I 
was able to come up with.

-Brent

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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

On Jan 2, 2014, at 1:54 PM, Filip Pizlo  wrote:

> I think the goal should be that if you do introduce a temporary variable for 
> some reason, then being explicit about its type is better.  Consider that in 
> your second example, there might be 200 lines of code between the call to 
> optimalSize() and the call to setSize().  I that case, we're essentially 
> choosing between having the code reader see this:
> 
> auto newSize = optimalSize();
> 
> or this:
> 
> CGSize newSize = optimalSize();

I’m not sure that having the temporary created 200 lines before it was used 
would be improved with either of these cases! ;-)

Allowing the compiler to infer type seems like a big win, for all the same 
reasons it is for SML and other Hindley-Milner languages. Why must I manually 
enter stuff that the compiler should be able to determine for me?

Our development environments should be capable of showing us the resulting 
‘auto’ type, so I feel like requiring explicit type declarations are a step 
backwards.

-Brent


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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Brent Fulgham]

Hi,

On Jan 2, 2014, at 1:12 PM, Geoffrey Garen  wrote:

>> +auto newRenderer = textNode.createTextRenderer(style);
>> +ASSERT(newRenderer);
>> 
>> ….
>> 
>> +parentRenderer->addChild(newRenderer.leakPtr(), nextRenderer);
> 
> I think this use of “auto” is net harmful. 

I disagree. I think the use of auto is an improvement, because it makes it less 
likely that we have something like the following:

int wrong = something.get64BitInt(); // potential truncation

There are plenty of cases where we change the signature of functions from one 
type to another, sometimes promoting sizes. I haven’t seen us do a very 
consistent job of combing through sources to make sure all receiving variables 
are properly sized.

When we don’t use ‘auto’, we run the risk of assigning to variables that the 
compiler “makes work” by casting. We only know this is happening when the 
compiler generates a warning (and we look for that warning).

> I think the downsides outweigh the upsides here because reading code is more 
> common than writing code, and because it’s not *that* much typing to write 
> out "RenderPtr< RenderText>”. In this particular code, I think it’s 
> especially bad to disguise the type of a pointer in the render tree, since 
> we’re in the middle of a transition to a new type of pointer, and so it’s 
> important to know if you’re looking at code that does the new thing or the 
> old thing.

Don’t we have this same problem with all of our JavaScript, Python, and Ruby 
code? We don’t have type specifications in those languages, but we manage to 
build large software with them as well.

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

Re: [webkit-dev] Windows a Release Build Broken

[Brent Fulgham]

> On Dec 27, 2013, at 9:26 AM, Joseph Pecoraro  wrote:
> 
> Windows bots on build.webkit.org are now green.

Thanks!

> Thanks for pointing me to the fixes in bugzilla comments.

Sorry to disturb your holiday, but thanks for fixing it. :)

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

[webkit-dev] Windows a Release Build Broken

[Brent Fulgham]

The changes in Bug 126091 breaks the Windows Release build.

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

-Brent

Sent from my iPad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Migration to Visual Studio 2013 Is Happening Now

[Brent Fulgham]

Hi Ossy,

I’m not sure what’s going on. Those bots do have VS2013 on them. It looks like 
a process may be locking the build log, preventing anything from happening.

I’ll look into it ASAP.

Thanks,

-Brent

On Dec 20, 2013, at 2:45 AM, Osztrogonác Csaba  wrote:

> Hi,
> 
> It seems the Windows EWS bots should be updated too:
> http://webkit-queues.appspot.com/queue-status/win-ews
> 
> Ossy
> 
> Brent Fulgham írta:
>> I am landing changes to switch our builds over to Visual Studio 2013.  You 
>> can assume I know about any build failures on the Windows port. However, 
>> please let me know if you encounter any problems on non-Windows platforms 
>> ASAP.
>> Thanks,
>> -Brent
> 

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

[webkit-dev] Migration to Visual Studio 2013 Is Happening Now

[Brent Fulgham]

I am landing changes to switch our builds over to Visual Studio 2013.  You can 
assume I know about any build failures on the Windows port. However, please let 
me know if you encounter any problems on non-Windows platforms ASAP.

Thanks,

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

[webkit-dev] Migration to Visual Studio 2013 Starts in About 12 Hours

[Brent Fulgham]

Hi floks!

Last week I promised that we would be moving to Visual Studio 2013 builds this 
Friday (tomorrow). I plan to start this work tomorrow morning, and hope to have 
everything completed within a couple of hours.

This should not impact non-Windows ports, so I anticipate minimal problems for 
most of you.

I am also on bot-watch duty this week, so I am in a great position to see if my 
changes create any problems (and of course, fix them). However, I do encourage 
you to e-mail me if you encounter build problems once I land the changes to our 
project files.

Hopefully this will be a smooth transition, and we can all start enjoying the 
new compiler features as soon as possible!

Best regards,

-Brent


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

Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013

[Brent Fulgham]

Hi Alex,

There are a few items missing from VS2012 (see 
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx) that we are 
already using in the Mac-specific source code:

1. Variadic Templates
2. Initializer Lists
3. Explicit conversion operators
4. Deleted functions

None of those items are supported in VS2012, and we would like to expand their 
use to the rest of WebKit.  Clang and GCC already support these features, so 
VS2012 (and earlier) hold the rest of the project back.

-Brent


On Dec 6, 2013, at 4:05 PM, Alex Christensen  
wrote:

> Is there any advantage of VS2013 instead of VS2012?  I've been using VS2012 
> for a while, and it works fine.  It also has the C++11 features we want to 
> use.  Staying one version behind the latest usually prevents updates from 
> breaking things.
> 
> Alex Christensen
> 
> 
> On Fri, Dec 6, 2013 at 3:53 PM, Brent Fulgham  wrote:
> Hi Everyone,
> 
> We are working hard to move WebKit toward stronger adoption of C++11 
> features, such as variadic templates, ranged for-loops, and initializer 
> lists. Unfortunately, this effort has been hampered by the small subset of 
> C++11 features available in Visual Studio 2010.
> 
> You can get a feel for the level of C++11 support in the last few versions of 
> Visual Studio here:
>   http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx
> 
> With Visual Studio 2013, we finally have access to a compiler that supports 
> the major C++11 features we need. Consequently, we intend to switch to VS2013 
> and begin taking advantage of these new language constructs.
> 
> Over the next week we will be landed a series of source changes that allow 
> WebKit to be built with VS2013, but will continue to build with VS2010 on our 
> build machines.  Next Friday, we plan to land project file changes to switch 
> to the new compiler, and will simultaneously convert our build system to use 
> VS2013 as well.
> 
> Once the revised project files are landed, we will no longer be officially 
> supporting Visual Studio 2010 as a compiler target.
> 
> For those playing at home, you can track progress by following 
> https://bugs.webkit.org/show_bug.cgi?id=125192.
> 
> WebKit continues to build with the free “Visual Studio 2013 Express” 
> software, so I do not anticipate that this change will block any external 
> developers from running Windows builds.
> 
> Thanks,
> 
> -Brent
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> 
> -- 
>  
> Alex Christensen
> 
> FlexSim Software Products, Inc.
> 
> 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
> 
> Voice: 801-224-6914 | Fax: 801-224-6984
> 
> Email: al...@flexsim.com
> 
> URL: www.flexsim.com
> 
>  
> 
>  
> This message may contain confidential information, and is intended
> 
> only for the use of the individual(s) to whom it is addressed. 
> 
> 

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

[webkit-dev] WebKit, C++11, and Visual Studio 2013

[Brent Fulgham]

Hi Everyone,

We are working hard to move WebKit toward stronger adoption of C++11 features, 
such as variadic templates, ranged for-loops, and initializer lists. 
Unfortunately, this effort has been hampered by the small subset of C++11 
features available in Visual Studio 2010.

You can get a feel for the level of C++11 support in the last few versions of 
Visual Studio here:
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

With Visual Studio 2013, we finally have access to a compiler that supports the 
major C++11 features we need. Consequently, we intend to switch to VS2013 and 
begin taking advantage of these new language constructs.

Over the next week we will be landed a series of source changes that allow 
WebKit to be built with VS2013, but will continue to build with VS2010 on our 
build machines.  Next Friday, we plan to land project file changes to switch to 
the new compiler, and will simultaneously convert our build system to use 
VS2013 as well.

Once the revised project files are landed, we will no longer be officially 
supporting Visual Studio 2010 as a compiler target.

For those playing at home, you can track progress by following 
https://bugs.webkit.org/show_bug.cgi?id=125192.

WebKit continues to build with the free “Visual Studio 2013 Express” software, 
so I do not anticipate that this change will block any external developers from 
running Windows builds.

Thanks,

-Brent



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

Re: [webkit-dev] C stack direction

[Brent Fulgham]

On Nov 21, 2013, at 2:14 PM, Darin Adler  wrote:

> On Nov 21, 2013, at 5:33 AM, Steven Coul (scoul)  wrote:
> 
>> But since it's WTF functionality that isn't being used in another component 
>> atm. I would tend to keep it.
> 
> Actually, we wouldn’t do that. WTF is only for WebKit, not intended to be a 
> general purpose library. We don’t keep things in it that we aren’t using.

Plus, the code is always present in the source repository. It's not lost if we 
remove it from the working set we build today.

-Brent

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

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Brent Fulgham]

On Oct 14, 2013, at 8:29 PM, Justin Haygood  wrote:

> Would it be possible to use Media Foundation with a fall back? You can’t 
> depend on Media Foundation even on Windows Vista+ anyway (N editions don’t 
> have it), but it’s a COM API so you can detect that it is not available to 
> use something else.

Sure. The media code currently has fallback support (at least in the Apple 
port) to cascade from AVFoundation back to QuickTime if needed.

The only downside is needing to provide implementations for each fallback path 
you want to support.

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

Re: [webkit-dev] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Brent Fulgham]

The only problem with Media Foundation is that it is Vista-and-newer only.  
There is no Windows XP version.

-Brent

On Oct 14, 2013, at 10:23 AM, Brent Fulgham  wrote:

> Alex, Brendan:
> 
> I do think that something like Media Foundation would be a useful way to go, 
> since WinCairo is pretty solidly Windows-only.
> 
> -Brent
> 
> 
> On Oct 14, 2013, at 10:00 AM, Brendan Long  wrote:
> 
>> On 10/14/2013 10:39 AM, Mital Vora wrote:
>>> * are we considering any other possibilities besides gstreamer like ffmpeg 
>>> (http://www.ffmpeg.org/) or any other. 
>> By the way, if this is just for Windows, you may want to look at Media 
>> Foundation.
>> 
>> Also, I took at look at the media players before Chromium was removed, and I 
>> didn't see an FFMPEG media player. Maybe Chromium's media player has always 
>> been in the Chromium tree instead of the WebKit tree.
>> ___
>> 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] [WinCairo] : ENABLE_VIDEO => how to activate HTML5 video tag ?

[Brent Fulgham]

Alex, Brendan:

I do think that something like Media Foundation would be a useful way to go, 
since WinCairo is pretty solidly Windows-only.

-Brent


On Oct 14, 2013, at 10:00 AM, Brendan Long  wrote:

> On 10/14/2013 10:39 AM, Mital Vora wrote:
>> * are we considering any other possibilities besides gstreamer like ffmpeg 
>> (http://www.ffmpeg.org/) or any other. 
> By the way, if this is just for Windows, you may want to look at Media 
> Foundation.
> 
> Also, I took at look at the media players before Chromium was removed, and I 
> didn't see an FFMPEG media player. Maybe Chromium's media player has always 
> been in the Chromium tree instead of the WebKit tree.
> ___
> 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] Wink browser

[Brent Fulgham]

Fantastic work! I can't wait to see what you do with it.

-Brent

Sent from my iPad

> On Oct 10, 2013, at 6:08 PM, Alex Christensen  
> wrote:
> 
> With the removal of Chromium and Qt, there are no projects of which I am 
> aware that allow Windows users to use WebKit with content from the open 
> internet. I've started a web browser project I'm calling "Wink" to get the 
> public to use WebKit on Windows, and I'm collecting crash reports with stack 
> traces to allow me to locate and fix common crashes.
> 
> I've created Winkbrowser.org and Winkbrowser.org/nightly.php as a start. 
> Could whoever manages nightly.webkit.org please send me some example code? 
> You might have noticed that writing aesthetically pleasing php isn't exactly 
> my strength. 
> 
> I hope this will be seen as beneficial to the WebKit community. 
> 
> Alex Christensen 
> ___
> 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] [WinCairo] : is ACCELERATED COMPOSITING under progress ?

[Brent Fulgham]

On Oct 7, 2013, at 11:32 AM, Urbain EGIS  wrote:

> Expecting ACCELERATED_COMPOSITING along with WinCairo, I noticed come 
> conflicts raised by building WebKit over MsDev 2010. Looks like 
> ACCELERATED_COMPOSITING is sort of  "wired" to CoreAnimation (and 
> CoreGraphics).
> 
> So is there any plan to make WinCairo sensitive to HW acceleration ? 
> Regardless of Corexxx stuff… ?

Yes. This will be based on the Texture Mapper code, which is partially working 
under WinCairo.  But work is stalled at the moment due to time constraints.

-Brent




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

Re: [webkit-dev] Please install shellwords on the bots

[Brent Fulgham]

It appears that Shellwords is part of the standard Ruby install we use on the 
Cygwin-based Windows systems.

-Brent

On Oct 6, 2013, at 2:06 PM, Filip Pizlo  wrote:

> 
> On Oct 6, 2013, at 2:00 PM, Benjamin Poulain  wrote:
> 
>> On 10/6/13, 1:54 PM, Filip Pizlo wrote:
>>> This bug: https://bugs.webkit.org/show_bug.cgi?id=120696
>>> 
>>> Is for making run-javascriptcore-tests run all of the tests in
>>> parallel and in a way that is aware of our multiple tiers.  It vastly
>>> improves JSC test coverage.
>>> 
>>> Right now, the script will refuse to do anything if your machine
>>> doesn't have the Ruby shellwords package installed.  Eventually I'll
>>> change that to make it just fail.
>>> 
>>> Please install shellwords on the bots so that this script can work.
>>> 
>>> (And no, I don't see an easy alternative to using shellwords for this
>>> testing infrastructure.  It would take a lot more code if we didn't
>>> want to use shellwords.  So, you should install shellwords to run
>>> javascriptcore tests.  It's already installed by default on a lot of
>>> OS's.)
>>> 
>>> I'll be landing this patch soon.  We need the test coverage.
>> 
>> Could run-javascriptcore-tests just install shellwords when it is missing?
> 
> Probably.
> 
>> 
>> There is a precedent of this, webkit-patch downloads every missing
>> packages, making it easy to use without installing the dependencies.
> 
> In the case of shellwords, the majority of WebKit developers will already 
> have it.  It’s part of the Ruby standard library as of version 2.
> 
>> 
>> Benjamin
>> 
>> ___
>> 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] Proposal: Use ICU in WebKit code

[Brent Fulgham]

The WinCairo port is as close to the AppleWin port as possible. It uses ICU and 
I have no intention of changing that.

The WinCE port is maintained by Patrick Gangsterer. I believe that this port 
does not want to use ICU, preferring to use the limited subset of i18n features 
provided by the operating system.

I have heard from a number of people, mainly using WebKit in resource 
constrained environments, who prefer to omit ICU due to its relatively large 
footprint. But many of their concerns about library size might be satisfied by 
rebuilding ICU with settings that omit the large encoding database. This makes 
sense if their use cases do not need these features.

-Brent

Sent from my iPad

> On Oct 4, 2013, at 11:48 PM, Dirk Schulze  wrote:
> 
> 
>> On Oct 5, 2013, at 7:37 AM, Darin Adler  wrote:
>> 
>> Any thoughts on this? I am not sure what the status of the WinCE port is, 
>> but I’d like to hear from the maintainers of that port on the port status 
>> and their view on this strategy.
> 
> Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a 
> long time ago and already removed. Probably I was wrong.
> 
> Greetings,
> Dirk
> ___
> 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] Announcement: CSS3_TEXT_DECORATION flag

[Brent Fulgham]

Yes, WinCairo uses the new inspector.

On Oct 4, 2013, at 11:45 AM, Antonio Gomes  wrote:

> All (?wincairo I'm not sure?) ports on trunk use the new Inspector,
> and the old one is being removed:
> https://bugs.webkit.org/show_bug.cgi?id=122295
> 
> On Fri, Oct 4, 2013 at 2:24 PM, Sam Weinig  wrote:
>> Or better yet, enable it for all ports on ToT.
>> 
>> -Sam
>> 
>> 
>> On Oct 4, 2013, at 11:03 AM, Timothy Hatcher  wrote:
>> 
>> Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?
>> 
>> I have a legitimate use for -webkit-text-decoration-color that would allow
>> me to eliminate a hack in the Inspector.
>> 
>> — Timothy Hatcher
>> 
>> 
>> On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield  wrote:
>> 
>> Hello, all!
>> 
>> Between the current and previous versions of the CSS3 Text spec, the text
>> decoration section was split out into its own spec [1] [2] [3]. Because of
>> this shift, I’m going to be creating a new compile-time flag:
>> CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in
>> [4]. For those who wish to follow progress, the feature bug is at [5]. The
>> first thing I am working on is the text-decoration-skip: ink property [6]. I
>> will also be migrating existing text-decorations code from behind the
>> existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
>> 
>> Thanks,
>> Myles C. Maxfield
>> 
>> [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
>> [2] http://www.w3.org/TR/css3-text/
>> [3] http://www.w3.org/TR/css-text-decor-3/
>> [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
>> [5] https://bugs.webkit.org/show_bug.cgi?id=58491
>> [6] https://bugs.webkit.org/show_bug.cgi?id=121806
>> ___
>> 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
>> 
> ___
> 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] WebGL :: Win32 => build successful and rendering assumed so => but white page

[Brent Fulgham]

Hi Hugo,

I think most of us in the WebKit project are aware of the missing pieces on the 
Apple Windows port, and have plans to rectify this.

However, I don’t understand what your needs are regarding WebGL and the Apple 
Windows port. This port is not licensed for use outside of Apple’s own 
products, and only exists as a mechanism for outside developers to debug 
problems and run early-warning builds of our current sources.

If you would like to embed a Windows version of WebKit for use in your own 
software, I would suggest using the WinCairo port, which seeks to be 
feature-compatible with the Apple Windows port.  An added bonus is that WebGL 
*already exists and works* in this port.

Alex Christensen has been working to further expand the WinCairo port, and 
often hangs out on our IRC channel.

Thanks,

-Brent

On Oct 3, 2013, at 1:49 PM, Hugo Machefer  wrote:

> Thanks a lot Timothy. For some: part of my job might consist in doing this 
> work  -for Windows-  required to actually display the result. Then, assuming 
>  compiles and runs WebGL content succesfully  for Mac  
> (probably provided some settings :  'defaults write com.apple.Safari 
> WebKitWebGLEnabled -bool YES'  specified from the terminal) would that be a 
> good approach, according to you, to watch step-by-step what happens across 
> Mac OS, by using efficient debugger, and report what is missing   -for 
> Windows-   ? To fill the gap...
> 
> Do you or anyone assess this analogy to mimic behaviours around OpenGLES2 
> from Mac OS X to WIN32 (involving Angle in-the-middle ;-) ?
> 
> PS: again, sorry for any piece of naivety or groundless indolence in my 
> analysis: these technical areas turn out to be new to me.
> 
> On Thu, Oct 3, 2013 at 6:15 PM, Tim Horton  wrote:
> On 2013.10.03, at 09:06, Hugo Machefer  wrote:
> 
>> Dear all. Might not the best place  -here-  to describe my issue [Win32], 
>> but I don't know where exactly this shall be submitted, as a novice by 
>> WebKit. To recap, I managed to compile  sources by Microsoft 
>> Visual Studio 2010 using CoreGraphics (ie without Cairo) in Debug mode. To 
>> activate WebGL, additionally, I have set: 
> 
> The AppleWin port (the one you describe) does not currently support WebGL. 
> Much of the underlying mechanism is implemented, but there’s still some work 
> required to actually display the result.
> 
>> #define ENABLE_WEBGL 1 
>> #define WTF_USE_3D_GRAPHICS 1 
>> #define WTF_USE_OPENGL 1 
>> #define WTF_USE_OPENGL_ES_2 1 
>> #define WTF_USE_EGL 1 
>> #define WTF_USE_GRAPHICS_SURFACE 1
>> 
>> I hope/guess this is the right approach => could anyone confirm ? Then LINK 
>> turns out to be "fortunate", by adding these libraries : 
>> translator_common.lib; libEGL.lib; libGLESv2.lib; preprocessor.lib; 
>> translator_glsl.lib; translator_hlsl.lib to WebKit sub-project.
>> 
>> However, execution fails by http://get.webgl.org. Indeed, HTML content 
>> pretends : 
>> Your browser supports WebGL
>> However: a blank area is displayed in place of expected movic 3D based 
>> cube... 
>> 
>> Apologize in case this concern forsooth comes to break any rule by 
>> lists.webkit.org , due to Windows matters...
>> 
>> ___
>> 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] PSA: WebKit2 and DrawingAreaImpl

[Brent Fulgham]

Hi Anders,

On Oct 1, 2013, at 6:19 PM, Anders Carlsson  wrote:

> I just wanted to let everyone know that we (Apple) are moving away from 
> DrawingAreaImpl and always using our tiled drawing area. Longer term we’d 
> like to remove DrawingAreaImpl completely since it was designed back when we 
> didn’t run in accelerated compositing mode all the time.

I believe that this only effects WebKit2, correct? If so, this will have no 
impact on the Windows port or the WinCairo port.

Thanks,

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

Re: [webkit-dev] WTF::fastMalloc

[Brent Fulgham]

So are you proposing to use the system allocator on Windows? Or would we keep 
using the existing FastMalloc implementation?

The current malloc logic has been the source of a number of mysterious crashes 
on Windows, so reverting to the system allocator might be a good thing for 
stability. I don’t know what the potential performance ramifications would be.

-Brent

On Oct 1, 2013, at 3:23 PM, Geoffrey Garen  wrote:

>> Apple's Windows port uses FastMalloc and the last measurements we took show 
>> it to be a large performance gain over the default Windows malloc 
>> implementation.
> 
> I believe those measurements were taken 5 Windows versions ago.
> 
>> While this port is only used by iTunes these days, we still would not want 
>> to regress its performance. Can the new allocator be made to work with 
>> Windows?
> 
> The set of porting tasks is the same set I outlined for GTK.
> 
> The Windows port is missing many performance features, including tiled 
> scrolling, LLInt, parallel garbage collection, DFG, and FTL. Given those 
> other major missing pieces, I don’t think this piece is worth the porting 
> time.
> 
> Geoff
> ___
> 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] Invalid file committed on the Webkit tree for windows

[Brent Fulgham]

This appears to have been corrected in r156161.

Thanks,

-Brent

On Sep 20, 2013, at 2:20 AM, Konstantin Tokarev  wrote:

> 
> 20.09.2013, 13:16, "Van Den Berghe, Vincent" 
> :
>> Hello,
>> 
>> When doing an SVN update to get the latest WebKit tree on Windows, I get the 
>> following error:
>> 
>> Failed to run the WC DB work queue associated with
>> 
>> 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources', work item
>> 
>> 193377 (file-install LayoutTests/fast/hidpi/resources/image?test.png 1 0 1 1)
>> 
>> Can't move 'C:\cygwin\home\vvdb\WebKit\.svn\tmp\svn-9BDA1924' to
>> 
>> 'C:\cygwin\home\vvdb\WebKit\LayoutTests\fast\hidpi\resources\image?test.png':
>> 
>> The filename, directory name, or volume label syntax is incorrect.
>> 
>> The reason is that “image?test.png' is not a valid filename on Windows. 
>> What’s worse, after this error the “svn cleanup” doesn’t work anymore 
>> because SVN tries to undo something that can’t be done by definition.
>> 
>> The only way to restore the local tree to a valid state is either (1) 
>> restore it from a backup, or (2) find the entry in .svn/wc.db (which is an 
>> sqlite database) and remove it manually.
>> 
>> There should be a way for these kinds of problems to be prevented or 
>> corrected as soon as possible (being able to “svn update” is kind of a 
>> fundamental thing). I can’t even patch because my tree is invalid L.
> 
> You can use git mirror instead of svn to be resistant to such issues when 
> they happen.
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] Loading and unloading webkit, threading, AtomicString and crashes

[Brent Fulgham]

I realized it was easier to light a candle than curse the darkness, so I 
converted the original e-mail to a bug.  Let's move discussion of this issue 
there:

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

Thanks!

-Brent

On Sep 15, 2013, at 10:52 AM, Alexey Proskuryakov  wrote:

> 
> 15.09.2013, в 08:53, "Van Den Berghe, Vincent" 
>  написал(а):
> 
>> static AtomicString lucidaStr("Lucida Grande");
> 
> 
> It is a mistake to use static objects with destructors in WebKit - we don't 
> want to waste time destructing them at process termination time. To fix this 
> issue, DEFINE_STATIC_LOCAL should be used.
> 
> In a somewhat dated checkout I have on this machine, I found 5 instances of 
> "static AtomicString" in WebCore, and none in WebKit/win.
> 
> - WBR, Alexey Proskuryakov
> 
> ___
> 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] Loading and unloading webkit, threading, AtomicString and crashes

[Brent Fulgham]

Hi Vincent,

Thank you for this very detailed explanation of the issue. I need to think 
about this for a bit.

It seems like the WK2 infrastructure should suffer from this same issue. 
Perhaps if we revived WK2 on Windows it would provide a better match to this 
situation.

Could you please do me a favor: copy the text of your e-mail and paste it into 
a new bug at https://bugs.webkit.org and cc me and Darin on this? Just file it 
under "WebKit Misc".

Thanks!

-Brent

Sent from my iPad

On Sep 15, 2013, at 8:53 AM, "Van Den Berghe, Vincent" 
 wrote:

> Hello again,
>  
> (for Brent Fulgham: codeword “onion”, I repeat, codeword “onion” J)
>  
> Context
> Consider embedding WebKit in an ASP.NET website (even though what follows is 
> valid in other scenarios). In order to do this, you need a (managed) thread 
> with a message loop. If you want this to work reliably, you make sure all 
> WebKit’s COM objects are created on that thread. If you chose not to, what 
> follows is still valid.
> Note that this thread doesn’t need to be the main process thread: in the case 
> of a worker process of a web server, you don’t even have access to that. For 
> WebKit, it just needs to be “a” thread with a message loop, as long as it’s 
> the same one.
>  
> When you instantiate a Webkit COM object for the first time, Windows’ COM 
> will ultimately call LoadLibrary on WebKit.dll. It will do so on the thread 
> that wants to instantiate the COM object. This initializes the CRT and 
> triggers a call to DllMain with the argument ul_reason_for_call set to 
> DLL_PROCESS_ATTACH.
> When the last reference to the last WebKit object is released, COM will NOT 
> call FreeLibrary(). COM doesn’t know the concept of “last object”, and will 
> keep the DLL around to avoid the overhead of loading it again should another 
> instance be needed.
> By default, your unmanaged DLL will remain loaded until the process is 
> terminated. The main process thread will then call FreeLibrary(), prompting 
> indirectly another call to DllMain with the argument ul_reason_for_call 
> hanksset to DLL_PROCESS_DETACH.
> The main thing to take away from this, is that the thread executing 
> DLL_PROCESS_ATTACH code and the thread executing DLL_PROCESS_DETACH code will 
> not necessarily be the same. In the above scenario, they will never be the 
> same.
> For those who prefer the horse’s mouth: http://msdn.microsoft.com/en-ure 
> us/library/windows/desktop/ms682583(v=vs.85).aspxus 
>  
> AtomicString
> Consider the following code:
>  
> LONG FontPlatformData::adjustedGDIFontWeight(LONG gdiFontWeight, const 
> String& family)
> {
> static AtomicString lucidaStr("Lucida Grande");
> if (equalIgnoringCase(family, lucidaStr)) {
> if (gdiFontWeight == FW_NORMAL)
> return FW_MEDIUM;
> if (gdiFontWeight == FW_BOLD)
> return FW_SEMIBOLD;
> }
> return gdiFontWeight;
>  
>  
> This is a method (one of many examples) with a static AtomicString object. 
> The constructor of lucidaStr will be executed in a thread-safe way (exactly 
> once) by the first thread that will enter this method. The C++ compiler will 
> generate code that will make sure of it, at least if the compiler obeys 
> C++0x, which mandates this behavior.
> Code will also be executed that registers the destructor  of lucidaStr so 
> that it is executed when the program terminates. The mechanism is similar to 
> functions registered with atexit(). Destruction order will be reverse 
> construction order, as expected.
> This code being in a DLL, it means that the destructor will be called when 
> the DLL is unloaded: after the the DLL_PROCESS_DETACH code of DllMain, the 
> CRT will do so.
> Given the context described above, it means that the destructor of an 
> AtomicString will be executed by a different thread than the one that 
> executed its constructor.
>  
> When an AtomicString is destroyed, the following method is executed:
>  
> void AtomicString::remove(StringImpl* string)
> {
> ASSERT(string->isAtomic());
> AtomicStringTableLocker locker;
> HashSet& atomicStringTable = stringTable();
> HashSet::iterator iterator = atomicStringTable.find(string);
> ASSERT_WITH_MESSAGE(iterator != atomicStringTable.end(), "The string 
> being removed is atomic in the string table of an other thread!");
> atomicStringTable.remove(iterator);
> }
>  
>  
> This will fail on the assertion, since the string was created on the string 
> table of a different thread.
> The process will therefore crash on termination. Every time.
>  
> Why this is relevant
> One can argue that for “eternal’ processes, this is not relevant. 
> Unf

Re: [webkit-dev] Changes in QtWebKit development

[Brent Fulgham]

On Sep 13, 2013, at 10:22 AM, Benjamin Poulain  wrote:

> On 9/13/13, 4:50 AM, Albisser Zeno wrote:
>> As many of you have probably noticed already, we have recently been focusing 
>> on a project called Qt WebEngine. Our WebKit efforts have therefore been 
>> reduced significantly over the past weeks.
>> While we will keep shipping QtWebKit with Qt for the foreseeable future, we 
>> want to concentrate our efforts on Qt WebEngine.
>> Therefore we are planning some changes to our development setup. In 
>> particular we are planning to remove our QtWebKit/Mac and QtWebKit/Windows 
>> builds from WebKit trunk. We will keep maintaining these platforms in a 
>> separate branch through the Qt project’s gerrit infrastructure.
>> This essentially means our presence in trunk will be reduced to 
>> QtWebKit/Linux.
>> 
>> We are planning to gradually implement the required changes within the next 
>> month.
>> If this proves to bring significant issues for some development, please do 
>> let us know and we can sort out a way to work together on a phase-out 
>> process.
> This is sad.
> 
> When "modules" of Qt are put on "maintenance", it is basically a synonym to 
> "it's unmaintained, just let it die". I am very unexcited about having one of 
> those in the tree along the live development from everyone else.
> It is unfair for all the ports who put real efforts in the WebKit opensource 
> project.
> 
> Realistically, how much development will go in QtWebKit/Linux? Why does it 
> stay in WebKit trunk if the two other ports are "maintained" in a branch?

Why don’t they create a WebKit branch and label it as their maintenance branch, 
and then we can purge the Qt stuff to lighten the size of the LayoutTests 
repository.

I don’t see much benefit in keeping the code in place if their plan is to be 
gone shortly.

-Brent

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

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

[Brent Fulgham]

Hi Vincent,

On Sep 13, 2013, at 1:34 AM, Van Den Berghe, Vincent 
 wrote:

> I’m embedding the Wincairo build of WebKit to generate PDF files from web 
> pages in an ASP.NET application.

Yay!

> Webkit isn’t really designed for such a scenario but with some careful 
> patching, a solution can be constructed which is “reasonably reliable”.   
> However, these patches touch on WebKit’s fundamental design decisions and I’m 
> reluctant to submit them without first some validation of someone who knows 
> the code better.   Some are more hacks than patches.

I would still encourage you to file bugs about these items so that there is 
documented history about the issue, and how to work around the problem.

WebKit is designed to be embedded in other applications — that’s exactly why I 
put together the WInCairo port in the first place. However, it has been 
optimized and coded for specific scenarios that may not match your needs. If we 
can make WebKit work better in these other areas (without breaking the existing 
use cases) I would be very strongly in favor of integrating such changes.

> So I became a member of the webkit-dev list and submitted the result of my 
> last frustrating bug hunt to see what happens. And it looks like it’s not 
> totally worthless.

I have always found the webkit-dev list to be extremely helpful. However, we 
will expect you to do some work, too — namely filing bugs and documenting what 
you are doing.  And, hopefully, contributing code to fix the issue!

Also, please CC me on any such bugs you file.

Thanks,

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

Re: [webkit-dev] TimerWindowWndProc and dangling page instances

[Brent Fulgham]

Hi Vincent and Mark:

On Sep 13, 2013, at 1:06 AM, Salisbury, Mark  wrote:

> Vincent,
>  
> Maybe some tips I’ve learned could be of help to you or others:
> ·Calling DestroyWindow will cause WebView::close() to be called (when 
> WM_DESTROY is received), but it does not cause WebView’s destructor to be 
> called, that doesn’t happen until the RCW holding the last COM reference is 
> destroyed and the COM ref count goes to 0.  This happens on the GC thread 
> (.NET internals), and deleting core webkit objects from a thread besides the 
> main thread can lead to undefined behavior.  I’d see crashes from concurrent 
> javascript GCs.  I fixed this by marshaling the delete call back to the main 
> thread (in every single COM exposed class).

I’m not sure this is limited to WebKit, or .NET.  I think destroying any GDI or 
other “User Interface” content outside of the main thread causes bad things to 
happen. I’ve seen this with MFC and base WinAPI programs as well.

To be fair, Mac OS has a number of similar constraints on how UI elements are 
handled, resulting in a bunch of infrastructure to allow things to be spun off 
for later processing on the main thread.

> ·WebView’s destructor calls DestroyWindow() on a tool tip window 
> which may or may not have been destroyed (at least on WinCE).  When embedding 
> in a .NET application, there can be a decent gap between the time the 
> WebView’s window is destroyed and the destructor is called.  It’s possible 
> that in the instances when Windows destroyed the tool tip window (because it 
> is a child of the webview window) that the tool tip handle is assigned to 
> another window by the time WebView’s destructor is called.  You can guess 
> what happens then when WebView’s destructor deletes the tool tip window.  
> Windows in the system disappear – sometimes causing a crash.  The only fix I 
> could figure out what to check to see if the window is still a tool tip 
> window before deleting it.

This sounds like a bug. Could you please file one and add me to the CC list on 
it?

> I don’t know if anyone wants to see a patch land for either of these 
> problems, they’re confined to embedded WebKit on Windows under .NET…

I’d love to see the patches.  You are obviously not the only person to suffer 
from these issues, and it would be great to at least document the issue and how 
to work around it.

Thanks!

-Brent


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

Re: [webkit-dev] Announcing new port: Nix

[Brent Fulgham]

> However, you've already clarified that you're going to improve WebRTC and 
> are, in fact, in the process of doing so.  Furthermore, you've clarified that 
> there is a demand for your port and human resources to maintain it.
> 
> I'm actually curious if anyone's opposed to supporting Nix port and why if so.

I'm really interested to see the port, and how they implemented things. There 
are likely to be many things that could be shared with some other ports.

It's not as though they want to provide their own JavaScript implementation! ;)

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

Re: [webkit-dev] Announcing new port: Nix

[Brent Fulgham]

Hi,

On 09/12/13, Osztrogonác Csaba   wrote:
> Improving cURL network backend (which used by Apple's WinCairo port too)
> 
> 
The WinCairo port is not an Apple project, though it is tied very closely to 
the existing Apple Windows port.

However, I am quite happy that people have been working on improving the 
libcURL support :-)

> I think these changes/fixes are benefit to the WebKit project. Some of
> them for all ports, some of them for only Linux users, some of them for
> only ARM devices, ...
> 
> 
The WinCairo port has certainly benefited from these changes. I know that an 
Icon bitmap bug fix was also applicable to the Apple Windows port, though I 
don't think it was something every actually triggered in field use.

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

Re: [webkit-dev] Changes to main Frame creation in WebCore

[Brent Fulgham]

I can take care of this for the Windows ports. Can you cc me on the bug, please?

Thanks,

-Brent

Sent from my iPhone

On Aug 18, 2013, at 4:33 PM, Andreas Kling  wrote:

> Hello everyone!
> 
> Just a friendly heads-up that I’m planning to land some changes to the way 
> main Frames are created in WebCore soon.
> 
> Previously, the WebKit layer would create a Frame with no owner element, and 
> Frame::create() would implicitly tell Page that this is going to be the 
> Page::mainFrame(). That mechanism leaves an awkward window in time where 
> Page::m_mainFrame is null, and the goal here is to get rid of that by having 
> Page construct the main Frame itself.
> 
> To do that, the Page constructor needs a FrameLoaderClient for the main 
> Frame, in addition to all the other PageClients it already takes as an 
> argument.
> 
> I have a patch here with WebKit1/mac and WebKit2 working, reviewed, and ready 
> to rock: 
> 
> Someone with know-how from WK1 ports will need to tweak the Page setup code 
> in the relevant WebKit1 initialization function(s) to add a FrameLoaderClient 
> to the PageClients passed to Page::Page(), and pick up the automatically 
> created Page::mainFrame() instead of creating their own brand-new Frame and 
> expecting it to become the main Frame.
> 
> Regards,
> Andreas
> ___
> 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] WebGL on Windows

[Brent Fulgham]

Let’s do it!

-Brent

On Aug 2, 2013, at 1:57 PM, Benjamin Poulain  wrote:

> On Fri, Aug 2, 2013 at 1:09 PM, Alex Christensen  
> wrote:
> In the near future I plan to enable WebGL on the AppleWin and WinCairo ports.
> 
> This change will require the addition of 2 dlls from ANGLE for anyone who 
> wants to use WebGL on Windows: libEGL.dll (58kb) and libGLESv2.dll (917kb).  
> I’ve soft linked these dlls so that WebKit will work without WebGL for anyone 
> who does not want to ship the additional dlls.  This change will also add 
> about 30 seconds to the clean build time of these ports.
> 
> Yay! Great job.
> 
> Benjamin
> ___
> 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] Windows Build Broken?

[Brent Fulgham]

Hi Rakesh,

On Aug 2, 2013, at 1:29 AM, Rakesh Sadhu  wrote:

> But I am facing one more  problem , my release winlauncher launches properly 
> whereas 
> debug winlauncher fails with the message "Failed to determine path to AAS 
> Directory”.

WebKit requires certain support DLLs to run properly (e.g., libxml2.dll, 
zlib1.dll, cairo.dll).  For the standard Apple build, these live in the Program 
Files directory and will be installed on your system if you have iTunes. We do 
not have an installer or canonical location for the WinCairo port’s support 
libraries; usually they are just copied to the same directory as the 
application.

> In the file DLLLauncherMain.cpp ::moidfypath 
> 
> //#if defined(_M_X64)
> static const wstring pathPrefix = L"C:\\Program Files\\Common 
> Files\\Apple\\Apple Application Support";
> //#else
>// static const wstring pathPrefix = L"C:\\Program Files (x86)\\Common 
> Files\\Apple\\Apple Application Support";
> //#endif
> 
> I commented above lines , but i was encountering another problem " 
> msvcr80.dll" missing .

You could also just return true without doing anything, which is probably the 
right thing to do for the WinCairo port.

The missing “msvcr80.dll” makes me think you have some VS2005-based support 
library DLLs in your path. The current set of WinCairo support dlls are all 
build with VS2010, and do not link against this old runtime.

-Brent





> 
> So is it like , my windows somehow got corrupted and i need to redo all or is 
> there any work around for this .
> 
> regards
> RSadhu
> 
> 
> Subject: Re: [webkit-dev] Windows Build Broken?
> From: bfulg...@apple.com
> Date: Thu, 1 Aug 2013 09:50:11 -0700
> CC: mital.d.v...@gmail.com; webkit-dev@lists.webkit.org
> To: rakeshsa...@hotmail.com
> 
> Please review your build log.  The problem is the following:
> 
> "fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or 
> directory”
> 
> You do not have the DirectX SDK installed, as documented in Step 4 of 
> http://www.webkit.org/building/tools.html.
> 
> -Brent
> 
> 
> On Aug 1, 2013, at 1:46 AM, Rakesh Sadhu  wrote:
> 
> Hi ,
> I couldn't fix the problem  with vs2005.
> Now I am trying to build with vs2010 and it fails too.
> here is the pasebin link : http://pastebin.com/W0YyGXZG
> Kindly guide.
> 
> 
> regards
> RSadhu
> 
> 
> Date: Tue, 23 Jul 2013 07:21:23 +0530
> Subject: Re: [webkit-dev] Windows Build Broken?
> From: mital.d.v...@gmail.com
> To: rakeshsa...@hotmail.com
> CC: webkit-dev@lists.webkit.org
> 
> Sorry Its not exactly the same error. but Its similar error which is present 
> in build-webkit
> 
> 
> I am trying to build using Visual Studio 2010 Express using commandline 
> cygwin tools
> 
> Thanks,
> 
> Mital Vora.
> 
> 
> On Tue, Jul 23, 2013 at 7:17 AM, Mital Vora  wrote:
> Hi, 
> 
> For the WinCairo Build as well these are the exact errors coming in the 
> buildbot
> 
> Building results into: 
> /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/WebKitBuild
> WEBKIT_OUTPUTDIR is set to: 
> C:\Projects\BuildSlave\win-cairo-release\build\WebKitBuild
> WEBKIT_LIBRARIES is set to: 
> Use of uninitialized value in print at 
> /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/Tools/Scripts/webkitdirs.pm
>  line 1644.
> 
> http://build.webkit.org/builders/WinCairo%20Release/builds/28414/steps/compile-webkit/logs/stdio
> 
> 
> 
> Windows and WinCairo Build from commandline seems broken.. can anybody help 
> fixing this.
> 
> Regards,
> 
> Mital Vora.
> 
> 
> On Sun, Jul 21, 2013 at 9:07 PM, Rakesh Sadhu  wrote:
> Hi ,
> I updated my webkit source code and tried to build it on windows machine , 
> and it fails to compile, with following error
> 
> Tools/Scripts/build-webkit --debug
> 
> Installing WebKitSupportLibrary...
> The WebKitSupportLibrary has been sucessfully installed in
>  /home/rsadhu/trunk/WebKitLibraries/win
> *
> Cannot find '/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
> 10.0/Common7/IDE/VCExpress.exe'
> Please execute the file 'vcvars32.bat' from
> 'C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\'
> to setup the necessary environment variables.
> *
> Died at /home/rsadhu/trunk/Tools/Scripts/webkitdirs.pm line 1627.
> 
> 
> Any Pointers on this?
> 
> 
> ___
> 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] Windows Build Broken?

[Brent Fulgham]

Please review your build log.  The problem is the following:

"fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or 
directory”

You do not have the DirectX SDK installed, as documented in Step 4 of 
http://www.webkit.org/building/tools.html.

-Brent


On Aug 1, 2013, at 1:46 AM, Rakesh Sadhu  wrote:

> Hi ,
> I couldn't fix the problem  with vs2005.
> Now I am trying to build with vs2010 and it fails too.
> here is the pasebin link : http://pastebin.com/W0YyGXZG
> Kindly guide.
> 
> 
> regards
> RSadhu
> 
> 
> Date: Tue, 23 Jul 2013 07:21:23 +0530
> Subject: Re: [webkit-dev] Windows Build Broken?
> From: mital.d.v...@gmail.com
> To: rakeshsa...@hotmail.com
> CC: webkit-dev@lists.webkit.org
> 
> Sorry Its not exactly the same error. but Its similar error which is present 
> in build-webkit
> 
> 
> I am trying to build using Visual Studio 2010 Express using commandline 
> cygwin tools
> 
> Thanks,
> 
> Mital Vora.
> 
> 
> On Tue, Jul 23, 2013 at 7:17 AM, Mital Vora  wrote:
> Hi, 
> 
> For the WinCairo Build as well these are the exact errors coming in the 
> buildbot
> 
> Building results into: 
> /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/WebKitBuild
> WEBKIT_OUTPUTDIR is set to: 
> C:\Projects\BuildSlave\win-cairo-release\build\WebKitBuild
> WEBKIT_LIBRARIES is set to: 
> Use of uninitialized value in print at 
> /cygdrive/c/Projects/BuildSlave/win-cairo-release/build/Tools/Scripts/webkitdirs.pm
>  line 1644.
> 
> http://build.webkit.org/builders/WinCairo%20Release/builds/28414/steps/compile-webkit/logs/stdio
> 
> 
> 
> Windows and WinCairo Build from commandline seems broken.. can anybody help 
> fixing this.
> 
> Regards,
> 
> Mital Vora.
> 
> 
> On Sun, Jul 21, 2013 at 9:07 PM, Rakesh Sadhu  wrote:
> Hi ,
> I updated my webkit source code and tried to build it on windows machine , 
> and it fails to compile, with following error
> 
> Tools/Scripts/build-webkit --debug
> 
> Installing WebKitSupportLibrary...
> The WebKitSupportLibrary has been sucessfully installed in
>  /home/rsadhu/trunk/WebKitLibraries/win
> *
> Cannot find '/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 
> 10.0/Common7/IDE/VCExpress.exe'
> Please execute the file 'vcvars32.bat' from
> 'C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\'
> to setup the necessary environment variables.
> *
> Died at /home/rsadhu/trunk/Tools/Scripts/webkitdirs.pm line 1627.
> 
> 
> Any Pointers on this?
> 
> 
> ___
> 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] Ports not building as C++11?

[Brent Fulgham]

Hi Patrick,

On Jul 29, 2013, at 10:42 AM, Patrick East  wrote:

> There is support for C++11 on Windows Embedded Compact 2013 using the newer 
> VC11 compiler, but for CE 5, 6, or WEC 7 they will not be able to support it 
> since they are limited to the VC9 compiler. Afaik there doesn’t appear to be 
> any plans from Microsoft to back-port the newer compiler and run time to 
> support older versions of CE.

That’s too bad.  Can you give me an idea of how big a ‘market’ we are talking 
about for these older OS releases?  Are these targets likely to need or benefit 
from access to a ToT WebKit build?

> I realize that CE 5, 6, and 7 are probably not top priorities for the 
> community, but these changes will basically force dropping support for those 
> platforms. We do have some interest in keeping WebKit working for our 
> downstream build, so if it’s possible to make this change over to using C++11 
> in a way that can allow for building without the new features that would be 
> ideal. If there is anything we can do that help make this happen let me know.

I think the goal is to (at least initially) conditionalize the use of various 
C++11 idioms.  But I think we will soon reach a critical mass where we will 
assume the compiler supports the newer language constructs.

-Brent

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

Re: [webkit-dev] Ports not building as C++11?

[Brent Fulgham]

We can support auto and move semantics.  We cannot support ranged iterators 
until VS2012.

But at least it's a step in the right direction...

Sent from my iPad

On Jul 28, 2013, at 2:36 PM, Oliver Hunt  wrote:

> So wait, is everyone using C++11 now?
> 
> I dream of using auto…
> 
> :-D
> 
> On Jul 28, 2013, at 12:47 PM, Gergely Kis  wrote:
> 
>> Hi,
>> 
>> On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen  
>> wrote:
>>> became required in WebKit2. The only fallout will likely be the loss of the 
>>> Qt
>>> MIPS bot which is maintained by a third party and is too old.
>> The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks
>> ago, I just forgot to update the buildbot slave info file, did it now.
>> 
>> Best Regards,
>> Gergely
>> the 3rd party maintaining the MIPS bot :)
>> ___
>> 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] Ports not building as C++11?

[Brent Fulgham]

The only platform I know cannot support C++11 is WinCE, and that port is in 
favor of making the move to C++11 in anticipation of updated build tools from 
Microsoft.

What other platform are we talking about here? The GNU compilers have supported 
C++11 for a long time.

-Brent

Sent from my iPhone

On Jul 26, 2013, at 8:12 PM, Anders Carlsson  wrote:

> 
> On Jul 26, 2013, at 8:09 PM, Allan Sandfeld Jensen  wrote:
> 
>> On Friday 26 July 2013, Anders Carlsson wrote:
>>> Hi everyone,
>>> 
>>> when Oliver landed his “let’s break everything” patches in JSC the other
>>> day, I noticed that some of the follow-up build fixes by other ports were
>>> removing use of C++11 features (mainly nullptr).
>>> 
>>> Are there any ports that aren’t building as C++11? If so, why not?
>> Yes, and because C++11 is not supported on all the platforms we support. 
> 
> Could you please elaborate? What compilers are you using?
> 
>> We don't all have the option to not care about the platforms of a certain 
>> fruit 
>> themed vendor's 1 or 2 year old operating systems.
> 
> I don’t think this comment adds anything constructive.
> 
> Thanks,
> - Anders
> ___
> 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] Remove CSS_IMAGE_ORIENTATION Feature Guard

[Brent Fulgham]

Hi Everyone,

I haven't seen any action on https://bugs.webkit.org/show_bug.cgi?id=116555 (or 
https://bugs.webkit.org/show_bug.cgi?id=92330) in the past month.

I'd like to remove this logic unless there is some activity here.  We can 
always add it back in from SVN history if someone does want to work on it.

I'll submit a patch to remove this code on July 17th unless something changes.

Thanks,

-Brent



On Jun 4, 2013, at 10:15 PM, Gyuyoung Kim wrote:

> Hi,
> 
> I'm interested in this feature. So, I took Bug 92330 over. Though I rebased 
> the feature according to review comments, this feature doesn't work yet. So, 
> I have investigated why it doesn't work. However, unfortunately, I need to 
> have time a little further. If there is no big reason this patch should be 
> removed, I'd like to support this feature.
> 
> Gyuyoung.
> On Jun 5, 2013 9:45 AM, "Mike Lawther"  wrote:
> Fwiw, the original author is no longer working on Blink, and the code has 
> been removed from there.
> 
> mike
> 
> On Jun 5, 2013 1:24 AM, "Brent Fulgham"  wrote:
> We have code in WebKit that is protected by the ENABLE(CSS_IMAGE_ORIENTATION) 
> guard, but no active WebKit ports seem to enable this feature.
> 
> Is anyone currently working on (or planning to work on) this feature?
> 
> Since this CSS feature is currently in an early draft form, and is likely to 
> change, we may not want to retain this dead code as it will most likely 
> become obsolete very quickly.
> 
> If no one wants to claim ownership of this feature in the next few days, I 
> will submit a patch to remove the dead code.
> 
> Thanks,
> 
> -Brent
> ___
> 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