Re: [webkit-dev] webkit browser always minimzed on CentOS 7.1
You’re much more likely to reach people that know about using WebKit with GTK
on the webkit-gtk mailing list:
https://lists.webkit.org/mailman/listinfo/webkit-gtk
- Bem
On May 4, 2015, at 4:54 AM, Jerry Geis
ge...@pagestation.commailto:ge...@pagestation.com wrote:
So I looked closer at my functions...
void maximize(void) {
gtk_window_maximize(GTK_WINDOW(window));
gtk_window_fullscreen(GTK_WINDOW(window));
gtk_window_set_decorated(GTK_WINDOW(window), FALSE);
}
This function in particular I am calling. If I comment out the
gtk_window_fullscreen() function
the browser appears and is not minimized When I put this function back in -
the application
is always minimized and is NOT fullscreen.
Any thoughts?
Jerry
On Fri, May 1, 2015 at 4:23 PM, Jerry Geis
ge...@pagestation.commailto:ge...@pagestation.com wrote:
Hi all,
I had a project that worked great under CentOS 6.6.
I basically took webkitgtk-2.4.6 and compiled then took a small
browser.c file to great a browser. Worked great.
So now I'm trying to migrate that to CentOS 7.1
did the same thing - same steps as above and when I run
the webkit browser it is ALWAYS minimized.
If I right click on it, and say unminimize - it does for a brief second
I see the page and then it becomes minimized again.
Any thoughts on what might be happening here?
Thanks,
Jerry
___
webkit-dev mailing list
webkit-dev@lists.webkit.orgmailto: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] Filling the features.json files
On Apr 8, 2015, at 15:45, Benjamin Poulain benja...@webkit.org wrote: On 4/8/15 12:01 PM, Bem Jones-Bey wrote: On 4/7/15, 21:09, Benjamin Poulain benja...@webkit.org wrote: The only mandatory fields are name and status. What are the valid values for the “status” field, and what is the criteria for a feature to be classified under each value? -enabled-by-default tells if the feature is in WebKit nightly. -status is free text, it will be shown as it is. -shipped is the list of the first release versions shipping the feature. For the status text, I have not made up any rule yet. I used: -Done: fully functional, maybe some minor bugs left. -Prototyping: proof of concept kind of work. -In Development: anything in between the other two. Even something that barely work can use this. Outside status, you can also add comment if you want to clarify something, want feedback, etc. What do you think about having a version of “Done” for fully functional, but -webkit prefixed? For example, we’ve implemented all the features of CSS Shapes Level 1, the spec is in CR, but we still have some bugs to fix. I’d assume that would be past the prototyping phase at this point, but not quite Done, given that it’s still prefixed. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Filling the features.json files
On 4/7/15, 21:09, Benjamin Poulain benja...@webkit.org wrote: The only mandatory fields are name and status. What are the valid values for the “status” field, and what is the criteria for a feature to be classified under each value? Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] ASAN and WebKit on OS X
Hey folks, I'd like to get an ASAN build up and running. However, following the instructions on the Wiki (https://trac.webkit.org/wiki/ASanWebKit) isn't working for me. (And I had to modify them slightly since it looks like things are in slightly different places with Xcode 6.1?) Does anyone have more recent instructions? I'm still running OS X 10.9, if it matters. Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] ASAN and WebKit on OS X
It looks like most of the warnings I got during the build were spurious. The one real error I got is fixed by abucur's patch here: https://bugs.webkit.org/show_bug.cgi?id=137652 (Any objections to landing that?) I'll update the wiki page with my learnings. - Bem On 11/4/14, 17:28, Bem Jones-Bey bjone...@adobe.com wrote: Hey folks, I'd like to get an ASAN build up and running. However, following the instructions on the Wiki (https://trac.webkit.org/wiki/ASanWebKit) isn't working for me. (And I had to modify them slightly since it looks like things are in slightly different places with Xcode 6.1?) Does anyone have more recent instructions? I'm still running OS X 10.9, if it matters. Thanks, Bem ___ 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] Removing webkit prefix from CSS Shapes properties?
Sorry about the delay in responding, the last couple of days have been crazy. We have been working on fixing both the tests and any bugs in the implementation. It sounds like we should bring this up again once we've finished that work. However, to answer Sam's question about other implementations, Chrome and Opera have shipped unprefixed, and we're keeping the Blink Implementation in sync with the WebKit one, including importing the CSSWG test suite for shapes. Firefox and IE have not shipped an implementation yet, but both have given us positive signals. Thanks for the feedback, Bem On Oct 29, 2014, at 23:17, Benjamin Poulain benja...@webkit.org wrote: Any update on this? There are a quite a few open bugs for CSS shapes. A lot of tests are skipped too: http://trac.webkit.org/browser/trunk/LayoutTests/TestExpectations#L137 CSS Shapes is really neat, it would be great to polish the implementation and unprefix. Benjamin On 10/27/14, 11:46 AM, Sam Weinig wrote: Can you give us an overview of what other browsers have shipped CSS Shapes and how interoperable they are (e.g are they all passing a shared test suite)? -Sam On Oct 27, 2014, at 11:42 AM, Bem Jones-Bey bjone...@adobe.com wrote: Hey all, Chrome shipped CSS Shapes un-prefixed. The spec has been in CR for awhile now, with no changes in behavior. I keep on coming across content that uses CSS Shapes but doesn't use the prefixed version, so it doesn't work in Safari. Any objections to enabling un-prefixxed versions of CSS Shapes properties in WebKit? - Bem ___ 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] Removing webkit prefix from CSS Shapes properties?
Hey all, Chrome shipped CSS Shapes un-prefixed. The spec has been in CR for awhile now, with no changes in behavior. I keep on coming across content that uses CSS Shapes but doesn't use the prefixed version, so it doesn't work in Safari. Any objections to enabling un-prefixxed versions of CSS Shapes properties in WebKit? - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] OS X Mavericks build failing
Howdy, My build on Mavericks has stopped working, and I haven't changed anything except syncing to head and installing the Xcode patch that came out a couple of days ago. Since the bots are green, I can only assume it has something to do with the public SDK. I've filed a bug for this: https://bugs.webkit.org/show_bug.cgi?id=138108 Anyone know what the proper fix is? Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fall Contributors Meeting?
Hey all, At the WebKit contributors meeting, it was mentioned that there was a desire to move the meeting to the fall, and potentially having a meeting this fall to start that off. Given that fall is rapidly approaching, I figured I'd check in to see if there's still a plan for a fall meeting this year, or if it's going to be the same plan as usual for 2015. Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Planning on Requiring Python 2.7 Soon
We broke some of the python tests yesterday and fixed them today, so it is likely what you saw. On Sep 11, 2014, at 17:54, Gyuyoung Kim gyuyoung@webkit.orgmailto:gyuyoung@webkit.org wrote: FYI, all EFL bots have worked with Python ver. 2.7.6. However, there are some failing python tests on EFL port recently. Let me take a look it soon. Gyuyoung On Thursday, September 11, 2014, Brent Fulgham bfulg...@apple.commailto:bfulg...@apple.com wrote: 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.orgjavascript:; https://lists.webkit.org/mailman/listinfo/webkit-dev -- Sent from Gyuyoung Iphone ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] wkb.ug redirector broken?
What happened to wkb.ug? It's giving me 403 Forbidden (for example: http://wkb.ug/136577). - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: please sort WebCore.exp.in when you change it
On Jul 7, 2014, at 11:55 , Tim Horton timothy_hor...@apple.com wrote: On Jul 7, 2014, at 11:41 AM, Simon Fraser simon.fra...@apple.com wrote: We have a handy script that sorts the export file; please use it whenever you modify WebCore.exp.in: ./Tools/Scripts/sort-export-file Source/WebCore/WebCore.exp.in It’s also smart enough to require no arguments at all, and just sorts all of them! Any reason that we don't have check-webkit-style fail if these files aren't properly sorted? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Zoltan Horvath is now a WebKit reviewer
Awesome! Congratulations Zoltan! On Jun 11, 2014, at 09:31 , David Hyatt hy...@apple.com wrote: Hi all, I'm pleased to announce that you now have someone new to pester for layout and rendering patch reviews! Zoltan Horvath is now a WebKit reviewer. He has done some excellent work in layout and rendering. He has primarily worked on shapes code, but also did useful refactoring in areas like line layout. Congratulations, Zoltan! dave (hy...@apple.com) ___ 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] Blog post on the contributor's meeting?
At the meeting last week, we talked about having more blog posts on the WebKit blog. Perhaps we could start with one on the contributors' meeting itself? The easiest thing to do would be to do a roundup of posts written by attendees on their own blogs, assuming anyone has done that. I've written a post for the Adobe Web Platform Blog[1]; has anyone else written up their experiences? If so, I could draft such a roundup post. If not, I could write something up for the WebKit blog, but would like to have an idea of what we as a project would think as important to highlight. In addition, there are many sessions from the contributor meeting that don't have notes or anything on them on the meeting page[2]. If you have anything you could add for any of the sessions, that would be very useful. Thanks, Bem [1]: http://blogs.adobe.com/webplatform/2014/04/24/adobe-web-platform-goes-to-the-2014-webkit-contributors-meeting/ [2]: https://trac.webkit.org/wiki/April%202014%20Meeting ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone else having these problems with run-webkit-tests?
On Mar 26, 2014, at 16:40 , Bem Jones-Bey bjone...@adobe.commailto:bjone...@adobe.com wrote: On Mar 24, 2014, at 15:54 , Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: On Mon, Mar 24, 2014 at 3:32 PM, Bem Jones-Bey bjone...@adobe.commailto:bjone...@adobe.com wrote: On Mar 24, 2014, at 14:54 , Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: Same here :( On 3/23/14, 12:15 PM, Darin Adler wrote: When I use run-webkit-tests to run the entire test suite, on a debug build of TOT WebKit, on Mavericks, I’m having the following problems: - Towards the end of the run, the tests run slowly, over a second per test on my 3.5GHz i7 iMac with tons of memory, which is about 10X too slow I think. The sample shows the vast majority of the time is spent in JavaScript garbage collection. This is running mostly the svg/custom tests. Yep. The time from 31k to 33k is a long as from 0 to 31k :( - Towards the end of the run, instead of the 8 parallel copies of DumpRenderTree, only 1 copy of DumpRenderTree seems to run. This is running mostly the svg/custom tests. I think the problem is we can only run DumpRenderTree in parallel on different folders. Toward the end, everything left is one or two slow folders. The problem is partially that the sharding is folder-at-a-time, partially that the svg folder is big and slow, and partially that svg comes near the end of the alphabet (i.e., we don't start the big slow directory until close to the end of run, so there ends up being one big long pole). At some point we added code to run-webkit-tests to have a list of slow directories that got started towards the beginning. I don't remember if we did that before or after the Blink fork, but it would be easy to port it over from Blink if it was after. I'm pretty sure this was after the Blink fork. I did a quick look through the history, and I found this: http://src.chromium.org/viewvc/blink?revision=152697view=revision Is that the correct change? If it will make tests run faster in WebKit land as well, I'm more than happy to port it myself. :-) Yup, that's the one. Obviously the whole virtual test suite thing is less relevant, but you can use it for any directory you want. Well, I tried that patch, replacing virtual with svg, and it doesn't seem to have any effect on the speed of the run for me. But I'm also not 100% sure that I am seeing the slowness issue that others are reporting. (I also get 18 copies of DRT, not 8, so) In case it matters, I ran the tests with WTR, and I see the issue; however, it's not svg tests for me: it's http and ietestcenter tests, and a couple of others. So it doesn't look like it's related to a single batch of tests. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone else having these problems with run-webkit-tests?
On Mar 24, 2014, at 15:54 , Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: On Mon, Mar 24, 2014 at 3:32 PM, Bem Jones-Bey bjone...@adobe.commailto:bjone...@adobe.com wrote: On Mar 24, 2014, at 14:54 , Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: Same here :( On 3/23/14, 12:15 PM, Darin Adler wrote: When I use run-webkit-tests to run the entire test suite, on a debug build of TOT WebKit, on Mavericks, I’m having the following problems: - Towards the end of the run, the tests run slowly, over a second per test on my 3.5GHz i7 iMac with tons of memory, which is about 10X too slow I think. The sample shows the vast majority of the time is spent in JavaScript garbage collection. This is running mostly the svg/custom tests. Yep. The time from 31k to 33k is a long as from 0 to 31k :( - Towards the end of the run, instead of the 8 parallel copies of DumpRenderTree, only 1 copy of DumpRenderTree seems to run. This is running mostly the svg/custom tests. I think the problem is we can only run DumpRenderTree in parallel on different folders. Toward the end, everything left is one or two slow folders. The problem is partially that the sharding is folder-at-a-time, partially that the svg folder is big and slow, and partially that svg comes near the end of the alphabet (i.e., we don't start the big slow directory until close to the end of run, so there ends up being one big long pole). At some point we added code to run-webkit-tests to have a list of slow directories that got started towards the beginning. I don't remember if we did that before or after the Blink fork, but it would be easy to port it over from Blink if it was after. I'm pretty sure this was after the Blink fork. I did a quick look through the history, and I found this: http://src.chromium.org/viewvc/blink?revision=152697view=revision Is that the correct change? If it will make tests run faster in WebKit land as well, I'm more than happy to port it myself. :-) Yup, that's the one. Obviously the whole virtual test suite thing is less relevant, but you can use it for any directory you want. Well, I tried that patch, replacing virtual with svg, and it doesn't seem to have any effect on the speed of the run for me. But I'm also not 100% sure that I am seeing the slowness issue that others are reporting. (I also get 18 copies of DRT, not 8, so) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anyone else having these problems with run-webkit-tests?
On Mar 24, 2014, at 14:54 , Dirk Pranke dpra...@chromium.orgmailto:dpra...@chromium.org wrote: On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: Same here :( On 3/23/14, 12:15 PM, Darin Adler wrote: When I use run-webkit-tests to run the entire test suite, on a debug build of TOT WebKit, on Mavericks, I’m having the following problems: - Towards the end of the run, the tests run slowly, over a second per test on my 3.5GHz i7 iMac with tons of memory, which is about 10X too slow I think. The sample shows the vast majority of the time is spent in JavaScript garbage collection. This is running mostly the svg/custom tests. Yep. The time from 31k to 33k is a long as from 0 to 31k :( - Towards the end of the run, instead of the 8 parallel copies of DumpRenderTree, only 1 copy of DumpRenderTree seems to run. This is running mostly the svg/custom tests. I think the problem is we can only run DumpRenderTree in parallel on different folders. Toward the end, everything left is one or two slow folders. The problem is partially that the sharding is folder-at-a-time, partially that the svg folder is big and slow, and partially that svg comes near the end of the alphabet (i.e., we don't start the big slow directory until close to the end of run, so there ends up being one big long pole). At some point we added code to run-webkit-tests to have a list of slow directories that got started towards the beginning. I don't remember if we did that before or after the Blink fork, but it would be easy to port it over from Blink if it was after. I'm pretty sure this was after the Blink fork. I did a quick look through the history, and I found this: http://src.chromium.org/viewvc/blink?revision=152697view=revision Is that the correct change? If it will make tests run faster in WebKit land as well, I'm more than happy to port it myself. :-) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] C++ null pointers and the style guide
Hey all, I just noticed that the style guide claims that we should be writing a C++ null pointer as 0[1]. I was under the impression that we had left that by the wayside now that we have C++11 and nullptr goodness. Is that impression mistaken, or shall I update the style guide to say that we should be using nullptr in C++? - Bem [1]: http://www.webkit.org/coding/coding-style.html#zero-null ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web Components development will continue in a branch in near future
On 2/18/14, 13:54 , Maciej Stachowiak m...@apple.commailto:m...@apple.com wrote: On Feb 18, 2014, at 7:44 AM, Adam Barth aba...@webkit.orgmailto:aba...@webkit.org wrote: Hi Ryosuke, On Sat, Feb 15, 2014 at 4:07 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: Now that we've removed all of the existing shadow DOM implementations from trunk in http://trac.webkit.org/changeset/164131, I'm intending to work on new web components implementations in a branch based on the feedback Apple has given on public-webapps and www-style in near future, probably starting with custom elements. I'd like to implement them in a branch to not inadvertently introduce performance regressions. The old implementation on trunk resulted in 5% overall slowdown in the page load time but we didn't quantify that until we removed the feature entirely last year. That's probably because the feature was added over years as a pile of small changesets each of which introduced immeasurably small performance regressions. Development in a branch allows a faithful performance comparison between the two. The approach we were successful with in Blink was to restructure how we construct the render tree. At the time Blink branched from WebKit, the algorithm we both used to construct the render tree was N^2. The inner loop of the N^2 algorithm contained more complex DOM traversals due to shadow DOM. When you profile the code, it looks like shadow DOM is expensive, but the bigger win is just to remove the N^2 algorithm, which we've done in Blink. After removing the N^2 algorithm, shadow DOM related code falls off the profile completely. I hope you view this message as constructive feedback. My hope is that you'll be successful implementing shadow DOM, and I wanted to share what we've learned in case that's useful to you. Thanks, Adam. We hope that we will be successful implementing shadow DOM as well. Do you have any more specific pointers that Ryosuke et al could look at for the O(N^2) algorithm? Like a commit range or a function to look at? I think it may be: https://codereview.chromium.org/24350009 ___ 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)
On Jan 6, 2014, at 13:49 , Geoffrey Garen
gga...@apple.commailto:gga...@apple.com wrote:
Let me try to clarify with two more motivating examples:
(1) Nodes.cpp:
FunctionParameters::FunctionParameters(ParameterNode* firstParameter, unsigned
size)
: m_size(size)
{
unsigned i = 0;
for (ParameterNode* parameter = firstParameter; parameter; parameter =
parameter-nextParam()) {
auto pattern = parameter-pattern();
pattern-ref();
patterns()[i++] = pattern;
}
}
If I had to describe this algorithm in English, I’d say, “Collect and retain
all the [auto] from the list of parsed parameters.” I think that explanation
would be stronger if “[auto]” were a concrete noun.
Does anybody prefer auto in this context? If so, why?
While I wouldn't say that I prefer auto here, it doesn't really bother me in
this example. Personally, I would read that as Collect and retain all of the
patterns from the list of parsed parameters, and I'd say it the same way if
auto had been an explicit type.
(2) ApplyStyleCommand.cpp:
auto children = elementChildren(*dummySpanAncestor);
for (auto child = children.begin(), end = children.end(); child != end;
++child) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(*child))
toRemove.append(*child);
}
I don’t understand why we’re *’ing here. That’s a surprising idiom I haven’t
seen before, which I would expect to be a no-op. My first question when reading
this is, “What is the type of ‘child’, such that I would need to * it?”.
Is this *child” obvious to everyone else?
It's actually pretty obvious to me, but I've been spending a lot of time with
similar iterators lately. I don't think it's that much clearer without the
auro. I've definitely found this to be confusing in the codebase much before
auto entered the picture. (In this case, I'd argue strongly for using an
accessor method on the iterator or a temporary variable)
- Bem
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Importing W3C tests for HTML template elements
On Nov 21, 2013, at 00:01 , Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: Hi, There has been a lot of discussions about importing W3C tests. Since I'm already trying to enable HTML template elements, I've decided to take lead on this and add LayoutTests/w3c directory as we've previously come to consensus. I've posted a patch to import some of HTML template elements tests into LayoutTests/w3c/html-templates at https://bugs.webkit.org/show_bug.cgi?id=124699 Since W3C is planning to move all tests into web-platform-tests repository: https://github.com/w3c/web-platform-tests, I didn't feel the need to put it inside LayoutTests/w3c/web-platform-tests/html-templates but I can do that if someone feels strongly about it. I'm all for this. Are you aware of the script in Tools/Scripts/import-w3c-tests ? By default, it imports into LayoutTests/w3c. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Minimum supported Xcode version is changing
On Sep 20, 2013, at 18:25 , Mark Rowe mr...@apple.com wrote: On 2013-09-20, at 1:01 PM, Mark Rowe mr...@apple.com wrote: On 2013-09-20, at 12:59 PM, Bem Jones-Bey bjone...@adobe.com wrote: Did you fix it so that the build works on Mountain Lion when running Xcode 5? As of yesterday, the tree didn't build on Mountain Lion with Xcode 5, with the following linker error: Undefined symbols for architecture x86_64: __kCFURLCachePartitionKey, referenced from: _WKCachePartitionKey in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) __CFHostIsDomainTopLevel, referenced from: _WKIsPublicSuffix in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) I’ve never been able to reproduce this error myself. The WebKit nightly builds have been built with Xcode 5 for the last week or two now without problems. If you can email me your entire output of build-webkit off-list I’ll see if I can spot what’s going awry. This should be fixed with r156218. It works for me now, thanks. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Minimum supported Xcode version is changing
Did you fix it so that the build works on Mountain Lion when running Xcode 5? As of yesterday, the tree didn't build on Mountain Lion with Xcode 5, with the following linker error: Undefined symbols for architecture x86_64: __kCFURLCachePartitionKey, referenced from: _WKCachePartitionKey in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) __CFHostIsDomainTopLevel, referenced from: _WKIsPublicSuffix in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) On Sep 20, 2013, at 12:18 , Mark Rowe mr...@apple.commailto:mr...@apple.com wrote: Hi all, Just a friendly heads-up that the minimum supported Xcode version will be increasing to Xcode 4.6 later today. We’re doing this to ensure that WebKit is building with a compiler toolchain that supports all of the modern C++ features we care about. Xcode 4.6 has been available for several months so most people are already using it. If you're not, please take a few minutes to upgrade to the latest available Xcode version that is supported on your OS. For Lion users, this will mean visiting https://developer.apple.com/downloads/ to download Xcode 4.6.3. Mountain Lion users should upgrade directly to Xcode 5 via the App Storehttp://itunes.apple.com/us/app/xcode/id497799835?ls=1mt=12. Please let me know if you have any questions or concerns. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto: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] Linker error with Xcode 5 on OS X 10.8
Hey all, Upon installing Xcode 5 on 10.8.5, I get the following error when attempting to build the Mac port: Undefined symbols for architecture x86_64: __kCFURLCachePartitionKey, referenced from: _WKCachePartitionKey in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) __CFHostIsDomainTopLevel, referenced from: _WKIsPublicSuffix in libWebKitSystemInterfaceMountainLion.a(WebKitSystemInterface.o) I'm guessing this means that we just need an updated version of libWebKitSystemInterfaceMountainLion.a. I know that at least one other person has had the same issue, so this is also a PSA of sorts. In the meantime, I have switched back to Xcode 4, but would very much like to be able to go back to Xcode 5. :-) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] (no subject)
On Sep 13, 2013, at 13:12 , Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: Unsubscribe at https://lists.webkit.org/mailman/listinfo/webkit-dev I'm getting really tired of seeing these emails. How hard is it to open the URL attached on every email sent to this mailing list? I wonder if this is a gmail problem: I think gmail hides that by default when you are reading mail from a mailing list, like it tries to be helpful by hiding people's signatures by default as well. Maybe Kabeer can tell us if the footer on this message is visible in gmail. (Unfortunately, I have no idea how one would go about fixing that.) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo
On Jul 2, 2013, at 17:06, Maciej Stachowiak m...@apple.commailto:m...@apple.com wrote: On Jul 1, 2013, at 7:31 PM, Brady Eidson beid...@apple.commailto:beid...@apple.com wrote: On Jul 1, 2013, at 5:27 PM, Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: I concur. Maybe StyleResolver* styleResolverIfExists() StyleResolver styleResolver() ? I concur with this. For this entire discussion, this is where I was hoping it was headed. I like. Maybe we should use this naming pattern and type signature even when only one or the other variant exists? FWIW, I like this as well. I also like the idea of being consistent with this style even when only one exists. Is there a good reason why we wouldn't want to do that? I can only think of benefits. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] webkit-patch and clearing flags
Hey WebKit, Would it be reasonable for webkit-patch to not clear flags on an attachement when it obsoletes it if there's an r+? Maybe it doesn't actually matter (i.e. I know I can still commit the patch), but it bothers me when it clears away an r+ because I forgot to tell it --no-obsolete when I'm updating a patch for nits. - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] webkit-patch and clearing flags
On May 29, 2013, at 10:09 , Darin Adler da...@apple.com wrote: On May 29, 2013, at 9:21 AM, Bem Jones-Bey bjone...@adobe.com wrote: Would it be reasonable for webkit-patch to not clear flags on an attachement when it obsoletes it if there's an r+? Maybe it doesn't actually matter (i.e. I know I can still commit the patch), but it bothers me when it clears away an r+ because I forgot to tell it --no-obsolete when I'm updating a patch for nits. Yes, we should make some change like this. The problem is that it complicates writing a query that looks for reviewed-but-not-yet-landed patches. We need to solve that problem too. It’s valuable to keep the history of what has been reviewed. It’s valuable to conveniently find patches that have been reviewed but not landed. I don't see why it would make it more complex than the current situation. Right now, you have the following important cases for a patch that is reviewed but not yet landed: 1) the patch has an r+ flags, and is not obsoleted by a newer patch 2) the patch got an r+, and has been obsoleted by a newer patch for nits. 3) the patch got an r+, but it was cleared by webkit-patch and marked as obsolete, and there is a newer patch for nits I'm suggesting we make it that #3 can't happen, make webkit-patch not clear the flags when it marks a patch as obsolete, but only if it got an r+ (clearing the cq flag would still make sense here, though) Or do we also assume that #2 can't happen when looking for reviewed-but-not-yet-landed patches? (There is a variant of #2, where the patch with an r+ hasn't been marked as obsolete, but there is a newer patch uploaded, but I think it would just add noise to the current discussion, so I didn't include it, along with other corner cases that one could invent.) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Why is the team list in two places?
Hi all, I happened to notice today that we have a team list at http://www.webkit.org/team.html as well as the one at http://trac.webkit.org/wiki/WebKit%20Team. It looks like the team.html one is generated from contributors.json. Any reason why we couldn't just put the Areas of knowledge into contributors.json and then have those listed in team.html so we can get rid of the one on the Wiki and only have one place for this info? - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Why is the team list in two places?
On May 24, 2013, at 12:08 , Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org wrote: On Fri, May 24, 2013 at 8:07 AM, Bem Jones-Bey bjone...@adobe.commailto:bjone...@adobe.com wrote: I happened to notice today that we have a team list at http://www.webkit.org/team.html as well as the one at http://trac.webkit.org/wiki/WebKit%20Team. It looks like the team.html one is generated from contributors.json. Any reason why we couldn't just put the Areas of knowledge into contributors.json and then have those listed in team.html so we can get rid of the one on the Wiki and only have one place for this info? Looks like you just volunteered to fix that ;) Looks like it. Do you want to volunteer to review it? ;-) https://bugs.webkit.org/show_bug.cgi?id=116737 - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Ref counting questions
Hey all, I've read the document at http://www.webkit.org/coding/RefPtr.html, but I still have some questions about using RefPtrs. The first one is listed in the Improving this document section of the aforementioned documentation: • Perils of programming with TreeShared. What does that mean? What gotchas should I be aware of? (Heck, more details on any of the things in improving this document would be helpful, and I'll do my best to update the document with anything I learn if that's desired.) Also, I've noticed that there's both TreeShared and RefCounted, and they seem fairly similar to my uninitiated eye. What's the difference between the two and when should one use one or the other? Also, are there other templates/classes that I should be aware of? Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] CSS Exclusions: Implementing shape-outside for floats (bug 98664)
Hi all, We've been working on implementing the CSS Exclusions Spec (http://dev.w3.org/csswg/css3-exclusions/) here at Adobe. As part of that effort, I am beginning work on implementing support for shape-outside (http://dev.w3.org/csswg/css3-exclusions/#shape-outside-property) on floats (http://dev.w3.org/csswg/css3-exclusions/#floats-and-exclusions). I have filed bug 98664 to track this work. I'm sending out this mail just as a heads up and to see if anyone has any questions, concerns, comments, or problems with respect to this. Thanks, Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
