[webkit-dev] Web Inspector blog post draft
Hello everyone, I have put together a Web Inspector blog post draft ( http://webkit.org/blog/?p=1463) concerning the latest style editing improvements. Please speak up if you think something should be changed, added, or removed. -- Thanks, -alexander ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
Hi WebKit, As you might know, we have a shortcut to the inspector bug entry form: webkit.org/new-inspector-bug. We use it all over the place, our users like simplicity it introduces. However, we ended up with 10 (and counting) people on the CC list. Fixed CC list has obvious drawbacks: - each time we want to add / remove a person from the template, we need to make explicit request - new guys don't get updates when old bugs change - old guys get updates even though they are not interested anymore. Can we migrate to a more flexible approach (such as introducing webkit-inspec...@lists.webkit.org) where we would be able to subscribe / unsubscribe? _wms suggested that we discuss it here first. Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CSS cache and unfired events.
Hello. I'm currently working on a Webkit interface using an HTMLview filled with YUIlayout panels including an HTMLdocument to edit within. Once a change has been made to the HTMLdocument, we save the whole stuff in both CSS and HTML physical files. When reopening the interface, the HTML file is physicaly accessed but not the CSS and image files included in the HTML. The cache prevails. Primary effect is that, though the HTML contents seem to be correctly brought back (from cache indeed), the styles are not up to date. Secondary effect is, on reload call, that the styles are updated but the HTML contents disappear. I would like to assure the cache is correctly flushed on page closure, but it appears that neither unload nor pagehide event is fired upon Page::~Page run in the Webkit core. The page destructor closes backforward list then calls the PageCache::remove without finding any cached page for the HistoryItem passed and that's it. How could I ensure, from higher layers, that the CSS cache and HTML of the edited HTMLdocument are surely flushed from cache and not retrieved on subsequent calls without adding ?val=random tricks in the URLs of DOM elements. Obviously no-cache, must-revalidate and all these obsolescence tricks are of no interest here since, even if the document has to be no-cache accessed on loading, we should be able to edit an ultimately cachable document. Any advice or clue welcome. Thanks. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
You can also introduce a dummy email address, and then interested folks can use bugzilla's email preferences to watch that email address. This is perhaps a more lightweight version of using a mailing list as there is no mailing list. It was very common to use this approach on bugzilla.mozilla.org, with each component in the system having its own dummy email address auto-added. This allows developers to subscribe / unsubscribe from receiving email for various components in the bug system. -Darin On Wed, Feb 9, 2011 at 9:32 AM, Pavel Feldman pfeld...@chromium.org wrote: Hi WebKit, As you might know, we have a shortcut to the inspector bug entry form: webkit.org/new-inspector-bug. We use it all over the place, our users like simplicity it introduces. However, we ended up with 10 (and counting) people on the CC list. Fixed CC list has obvious drawbacks: - each time we want to add / remove a person from the template, we need to make explicit request - new guys don't get updates when old bugs change - old guys get updates even though they are not interested anymore. Can we migrate to a more flexible approach (such as introducing webkit-inspec...@lists.webkit.org) where we would be able to subscribe / unsubscribe? _wms suggested that we discuss it here first. Thanks Pavel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] code review tool changes
I just discovered that the review tool doesn't save the general comments, only inline ones (http://webkit.org/b/54121). This just got me when I clicked on the style bot to see what style checks had failed and lost my feedback :( This was particularly annoying as i had command-clicked the link (to open in a new tab) and the link actually forced the current page to navigate instead - http://webkit.org/b/54113 --Oliver On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote: On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: There's been a slew of changes to the code review tool. It's probably a good time to send a summary now that I don't intend to add significant new features. -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* Thank you for this in particular. Several times I've accidentally navigated away from a review and lost work. I just temporarily lost Internet connectivity while uploading a (large) review and when I came back to the review (same browser, etc.) all of my comments were lost. Is this functionality expected to work with Chrome 9 stable? When you click the publish button, we clear all the saved drafts. :( Otherwise we'd continue showing the draft comments alongside the published ones. I suppose I should find a way to make that happen when the publish actually succeeds instead. Thanks, -Ken -Ken -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. Ojan * Taking the next step and storing them online for non-security bugs (e.g. in S3 or appengine) would be a simple and welcome addition if someone feels moved. ** This currently only works if the patch includes the svn revision it was created at (i.e. it was created with SVN) or applies cleanly to trunk. Including the SVN revision in git diffs shouldn't be too hard. Again, if you feel moved to fix this, ping me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] code review tool changes
I just discovered that the review tool doesn't save the general comments, only inline ones (http://webkit.org/b/54121). This just got me when I clicked on the style bot to see what style checks had failed and lost my feedback :( This was particularly annoying as i had command-clicked the link (to open in a new tab) and the link actually forced the current page to navigate instead - http://webkit.org/b/54113 --Oliver On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote: On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: There's been a slew of changes to the code review tool. It's probably a good time to send a summary now that I don't intend to add significant new features. -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* Thank you for this in particular. Several times I've accidentally navigated away from a review and lost work. I just temporarily lost Internet connectivity while uploading a (large) review and when I came back to the review (same browser, etc.) all of my comments were lost. Is this functionality expected to work with Chrome 9 stable? When you click the publish button, we clear all the saved drafts. :( Otherwise we'd continue showing the draft comments alongside the published ones. I suppose I should find a way to make that happen when the publish actually succeeds instead. Thanks, -Ken -Ken -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. Ojan * Taking the next step and storing them online for non-security bugs (e.g. in S3 or appengine) would be a simple and welcome addition if someone feels moved. ** This currently only works if the patch includes the svn revision it was created at (i.e. it was created with SVN) or applies cleanly to trunk. Including the SVN revision in git diffs shouldn't be too hard. Again, if you feel moved to fix this, ping me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] code review tool changes
Thanks for the feedback. Please feel encouraged to let me and others know how you'd like these tools improved. Adam On Wed, Feb 9, 2011 at 10:49 AM, Oliver Hunt oli...@apple.com wrote: I just discovered that the review tool doesn't save the general comments, only inline ones (http://webkit.org/b/54121). This just got me when I clicked on the style bot to see what style checks had failed and lost my feedback :( This was particularly annoying as i had command-clicked the link (to open in a new tab) and the link actually forced the current page to navigate instead - http://webkit.org/b/54113 --Oliver On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote: On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell k...@google.com wrote: On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: There's been a slew of changes to the code review tool. It's probably a good time to send a summary now that I don't intend to add significant new features. -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* Thank you for this in particular. Several times I've accidentally navigated away from a review and lost work. I just temporarily lost Internet connectivity while uploading a (large) review and when I came back to the review (same browser, etc.) all of my comments were lost. Is this functionality expected to work with Chrome 9 stable? When you click the publish button, we clear all the saved drafts. :( Otherwise we'd continue showing the draft comments alongside the published ones. I suppose I should find a way to make that happen when the publish actually succeeds instead. Thanks, -Ken -Ken -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. Ojan * Taking the next step and storing them online for non-security bugs (e.g. in S3 or appengine) would be a simple and welcome addition if someone feels moved. ** This currently only works if the patch includes the svn revision it was created at (i.e. it was created with SVN) or applies cleanly to trunk. Including the SVN revision in git diffs shouldn't be too hard. Again, if you feel moved to fix this, ping me. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector blog post draft
On Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov apav...@chromium.orgwrote: I have put together a Web Inspector blog post draft ( http://webkit.org/blog/?p=1463) concerning the latest style editing improvements. Please speak up if you think something should be changed, added, or removed. I get an error page at this URL. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
Anything like this, PLEASE! The worst part, for me, is having to find that web inspector URL, and then giving it out to people. I just posted it on Twitter today, in fact. I cringe whenever I do. Eclipse also uses something like what Darin suggested, worked great for me, back in the day. On 2/9/11 12:53 PM, Darin Fisher wrote: You can also introduce a dummy email address, and then interested folks can use bugzilla's email preferences to watch that email address. This is perhaps a more lightweight version of using a mailing list as there is no mailing list. It was very common to use this approach on bugzilla.mozilla.org, with each component in the system having its own dummy email address auto-added. This allows developers to subscribe / unsubscribe from receiving email for various components in the bug system. -Darin On Wed, Feb 9, 2011 at 9:32 AM, Pavel Feldmanpfeld...@chromium.org wrote: Hi WebKit, As you might know, we have a shortcut to the inspector bug entry form: webkit.org/new-inspector-bug. We use it all over the place, our users like simplicity it introduces. However, we ended up with 10 (and counting) people on the CC list. Fixed CC list has obvious drawbacks: - each time we want to add / remove a person from the template, we need to make explicit request - new guys don't get updates when old bugs change - old guys get updates even though they are not interested anymore. Can we migrate to a more flexible approach (such as introducing webkit-inspec...@lists.webkit.org) where we would be able to subscribe / unsubscribe? _wms suggested that we discuss it here first. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector blog post draft
I'm logged in (as near as I can tell - link at the bottom says Log out), and still get the error. I don't have posting rights to the blog, nor do I want them. On 2/9/11 2:20 PM, Adele Peterson wrote: You have to be logged into the blog to read drafts. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the device element
Hi, El 7 de febrero de 2011 18:56, Adam Bergkvist adam.bergkv...@ericsson.com escribió: Hi, On 2011-02-04 19:21, Leandro Graciá Gil wrote: This is good news! Especially for the situations where WebCore can't directly access the hardware. One existing case of this we should keep in mind are the sandboxed environments, where both the probing and the connections must be requested to somewhere outside the sandbox. Usually this will require to communicate with another process, and in this case asynchronous messages are preferred to avoid delays and to make inter-process communication simpler. However I have to disagree in one point. The specification doesn't say anywhere that we should always present a dialog, only that the device element represents a device selector. The UI has been a central part of the discussions that lead up to the device element proposal. The reason for that is that it should enforce security. See the thread UI for enabling webcam use from untrusted content: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0149.html especially http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html You're right that we shouldn't limit ourselves by referring to the device selector as a dialog. I've renamed ChromeClient::runDeviceDialog to runDeviceSelector and the corresponding client interface accordingly. Thanks. I also think that this name, and more importantly this point of view, is more appropriate. Consider this completely valid use case: instead of asking repeatedly the user to select a device, a UA might decide to create some kind of internal device settings configuration panel to select a set of default devices. Later when visiting a page and clicking the device element the UA will automatically use the preferred devices from its internal settings if they are available and the page is trusted. Where is the dialog here? Couldn't you just see the internal device settings configuration panel, you mention, as the device selector that produces a device list that's reused several times? In that case you would skip the dialog and simply apply the predefined selections (similar to the case where a remember my choices check box would be available in the device dialog). Yes, of course. The reason I proposed that use case was to show that we should not force any dialog, but ask for selection in the way that the UA decides. This was just an example of what I mentioned in the previous paragraph and I'm glad that we agree on this. I agree that the device should perform selection, as the spec says. However as I've already explained I don't think we need for example a selection dialog for all use cases. Considering that we don't explicitly need a dialog to perform the selection, the only reason to bring lists of available devices back to WebCore is to send them again to a client, probably the same one we asked for probing. Also, if we consider the possibility of sandboxed environments then the device connection operation cannot be a synchronous operation as commented before. As mentioned above, I see a point in sending the list of available devices to WebCore to determine if a new Stream (or other device handler) should be created since this behavior should be consistent across platforms, regardless if the device is of type media or fishtank. So, does that mean that a WebCore platform-independent code is going to determine if a new device handler should be created? I think that some UAs may like to, for example, keep a track of trusted pages for specific types of devices to determine if such a handler should be created. And that is not likely to be implemented in the same way by all the different platforms even if they intend to perform a set of basic common security steps. I completely agree with you that the behaviour should be consistent across platforms, especially the security and privacy aspects, but I don't think that forcing the common code to use available device lists is the way to do it. If we want a consistent behaviour we should ask for it in the specification and leave the implementation specific details open, not the other way around. The device connection operation is not handled by the device element. The device element is used to simply select devices (similar to how you select a file with input type=file and get a File object which is just a handle to the actual file). The connection takes place when you use the device, e.g., when you play a Stream in a video element; and that will happen asynchronously. I think that we're not talking about exactly the same thing when we say connection, and probably I should have specified more. I'm not implying that data should flow from the moment we select the device (and we establish a connection in our model). The data should start flowing asynchronously when there is something to consume it, for example a video
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. Kevin - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 3:11 PM, Mark Rowe wrote: On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. Actually, I'm referring to what is still an open bug. (https://bugs.webkit.org/show_bug.cgi?id=27551) The issue in question is a change to try and move the definition of JSC / WTF export symbols into the headers rather than using the current export definition files. Resolving this issue is a pre-requisite for wx DRT support, and also blocks a bug related to defining export macros for C++ DOM bindings as well. Part of what fixing this bug entailed was adding a new header to WTF, I called it wtf/ExportMacros.h, which defined WTF_EXPORT and WTF_IMPORT so we could consolidate the export symbol attribute definition macros into one place in the tree, instead of copying and pasting the same logic (just with different XYZ_EXPORT and IMPORT names) into every config.h file. However, when I tried adding the WTF header, almost every port failed with some error, and it often had to do with header availability issues. (e.g. WebCore has access to this WTF header, but WebKit, or DRT, or JSC.exe doesn't, and won't unless you add it to some copied / forwarded header list). FWIW, I did get around to fixing most of the ports, but the reason this
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On 2011-02-09, at 16:21, Kevin Ollivier wrote: On Feb 9, 2011, at 3:11 PM, Mark Rowe wrote: On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. Actually, I'm referring to what is still an open bug. (https://bugs.webkit.org/show_bug.cgi?id=27551) The issue in question is a change to try and move the definition of JSC / WTF export symbols into the headers rather than using the current export definition files. Resolving this issue is a pre-requisite for wx DRT support, and also blocks a bug related to defining export macros for C++ DOM bindings as well. Part of what fixing this bug entailed was adding a new header to WTF, I called it wtf/ExportMacros.h, which defined WTF_EXPORT and WTF_IMPORT so we could consolidate the export symbol attribute definition macros into one place in the tree, instead of copying and pasting the same logic (just with different XYZ_EXPORT and IMPORT names) into every config.h file. However, when I tried adding the WTF header, almost every port failed with some error, and it often had to do with header availability issues. (e.g. WebCore has access to this WTF header, but WebKit, or DRT, or JSC.exe doesn't, and won't unless you add it to some copied / forwarded header list). I
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 4:28 PM, Mark Rowe wrote: On 2011-02-09, at 16:21, Kevin Ollivier wrote: On Feb 9, 2011, at 3:11 PM, Mark Rowe wrote: On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. Actually, I'm referring to what is still an open bug. (https://bugs.webkit.org/show_bug.cgi?id=27551) The issue in question is a change to try and move the definition of JSC / WTF export symbols into the headers rather than using the current export definition files. Resolving this issue is a pre-requisite for wx DRT support, and also blocks a bug related to defining export macros for C++ DOM bindings as well. Part of what fixing this bug entailed was adding a new header to WTF, I called it wtf/ExportMacros.h, which defined WTF_EXPORT and WTF_IMPORT so we could consolidate the export symbol attribute definition macros into one place in the tree, instead of copying and pasting the same logic (just with different XYZ_EXPORT and IMPORT names) into every config.h file. However, when I tried adding the WTF header, almost every port failed with some error, and it often had to do with header availability issues. (e.g. WebCore has access to this WTF header, but WebKit, or DRT, or JSC.exe doesn't, and won't unless you
[webkit-dev] EventTarget Changes Causes Safari Launch Problems
In a recent set of experiments in changes to XML processing, I added a new EventTarget class called XMLReader. As such, I had to add a toXMLReader() method to the EventTarget class. Previously, this has worked well but now, after updating this code to the latest trunk, I have a problem launching Safari (it crashes right at startup without even showing a window). It is unclear to me why it would have worked before but now does not. I've narrowed my troubles down to what I think is a virtual table change relating to the class structure although I really haven't proven that. If I hack my way around the need for the toXMLReader() method on EventTarget, doing some very unsavory things, the latest trunk with my changes and the latest version of Safari work fine. Any ideas why, within the last month, this would all change? Was I just lucky before? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
