[webkit-dev] Fooling with EWS and commit queue
Hi, I started making changes to the logic of EWS and commit queue, please e-mail me if something breaks, or even if something begins to behave more strangely than it did before. - Alexey ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebView and User Interface Restore
On Sep 21, 2014, at 7:48 PM, Daryle Walker wrote: > Do WebView instances participate in the Resume feature (with > +restoreWindowWithIdentifier: state: completionHandler:, etc.), or do I have > to manually handle their state (the web-view’s back-forward list and which > item is current) myself? I had to turn Resume back on before trying out. My code to bring back the windows worked, but there was nothing in them. I guess WebKit does not do state save/restore and apps like Safari do it manually. Is there any part of that wrong? Any hints on doing it manually? — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Type checking / casting helpers
Thanks Chris for taking the initiative to do this! New code looks much more pleasant to read now. On Thursday, September 25, 2014, Chris Dumez wrote: > Hi all, > > I started working on automatically generating the type *casting* helpers > for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until now, we were > generating only the type *checking* helpers using make_names.pl (e.g. > isHTMLDivElement()). The type *casting* helpers had to be manually > defined using NODE_TYPE_CASTS() macro. > > The type casting helpers are now automatically generated for most types. > Part of the solution involved using a templated function for type casting > because the types are forward-declared and we needed to do a > static_cast<>() (a reinterpret_cast<>() could be used with forward > declarations but wouldn't be safe due to multiple inheritance). > > I initially had macros in place so that toHTMLDivElement() would still > work and would be equivalent to downcast(). The feedback I > received is that we should get rid of these macros and just use > is() / downcast() everywhere. > The new style is very close to C++'s is_class() and Boost's > polymorphic_downcast(). > > I actually started updating the code to do this but I should have emailed > webkit-dev about this beforehand. I apologize for sending this message a > bit late. > > Please let me know if you have feedback / concerns / questions about this > change. I hope that this email gives you a better understanding of why I am > making this change. > > As I said before, the code base is not fully ported yet so the current > situation is not necessarily pretty. I will try and go through the > transition as fast as I can, provided that people don't raise any concerns > about this. > > Please also note that these new helpers still catch unnecessary type > checks / casts. As a matter of fact, those are now caught at build time > instead of linking time and should give you a nice "Unnecessary type check" > / "Unnecessary type cast" static assertion. > > Also note that the plan is to get rid of TYPE_CAST_BASE() macro entirely > and extend is<>() / downcast<>() to all types, not just Nodes. > > Kr, > -- > Chris Dumez - Apple Inc. > Cupertino, CA > > > > > -- - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Type checking / casting helpers
Hi all, I started working on automatically generating the type casting helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until now, we were generating only the type checking helpers using make_names.pl (e.g. isHTMLDivElement()). The type casting helpers had to be manually defined using NODE_TYPE_CASTS() macro. The type casting helpers are now automatically generated for most types. Part of the solution involved using a templated function for type casting because the types are forward-declared and we needed to do a static_cast<>() (a reinterpret_cast<>() could be used with forward declarations but wouldn’t be safe due to multiple inheritance). I initially had macros in place so that toHTMLDivElement() would still work and would be equivalent to downcast(). The feedback I received is that we should get rid of these macros and just use is() / downcast() everywhere. The new style is very close to C++’s is_class() and Boost’s polymorphic_downcast(). I actually started updating the code to do this but I should have emailed webkit-dev about this beforehand. I apologize for sending this message a bit late. Please let me know if you have feedback / concerns / questions about this change. I hope that this email gives you a better understanding of why I am making this change. As I said before, the code base is not fully ported yet so the current situation is not necessarily pretty. I will try and go through the transition as fast as I can, provided that people don’t raise any concerns about this. Please also note that these new helpers still catch unnecessary type checks / casts. As a matter of fact, those are now caught at build time instead of linking time and should give you a nice “Unnecessary type check” / “Unnecessary type cast” static assertion. Also note that the plan is to get rid of TYPE_CAST_BASE() macro entirely and extend is<>() / downcast<>() to all types, not just Nodes. Kr, -- Chris Dumez - Apple Inc. Cupertino, CA ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Windows EWS bots having issues
Hi, Now 8 machines are connected to the EWS server as Apple Windows EWS, but it seems 3 of them are out of order, and can't build anything. If they pick up a patch from the queue again and again, they only slow down the patch processing. Is there any chance if anybody from Apple can fix or power off them in the near future? Thanks. http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-4 Last Pass: 4 months ago http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-5 Last Pass: 1 month, 2 weeks ago http://webkit-queues.appspot.com/queue-status/win-ews/bots/APPLE-EWS-7 Last Pass: 1 month, 2 weeks ago br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Unprefixing CSS Grid (was: Easy bugs for grab)
On 9/25/14, 12:34 AM, Sergio Villar Senin wrote: On 23/09/14 10:28, Benjamin Poulain wrote: -Unprefix your favorite CSS property (easy to hard depending on the property). What's the policy for unprefixing properties? I thought that they're prefixed as long as the feature was experimental/under heavy development. Has it changed? (I'm particularly interested in unprefixing grid layout properties). The policies have not changed. From the data I have at the moment, I see a few reasons to keep the prefix on Grid Layout: -It is a major feature. -The spec is still a working draft, you are still helping the editor finishing the work. -As far as I know, nobody has shipped the unprefixed version yet, there is no urgency for compatibility. -What IE ships is not the current spec. -I have not seen much feedback from web developers, which is frustrating/annoying :( Once we are fully matching the latest spec and we have outstanding test coverage, we should unprefix the feature. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Easy bugs for grab
On 23/09/14 10:28, Benjamin Poulain wrote: > -Unprefix your favorite CSS property (easy to hard depending on the > property). What's the policy for unprefixing properties? I thought that they're prefixed as long as the feature was experimental/under heavy development. Has it changed? (I'm particularly interested in unprefixing grid layout properties). BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
