Re: [webkit-dev] New Feature - Resource Timing
On 5/20/11 1:51 PM, Maciej Stachowiak wrote: Presumably the embedding application would need to require explicit user consent to enable the feature. I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, enable[d]-by-default with a hidden pref to disable sounds like an extremely weak approach to protecting user privacy. I can't speak to the security or insecurity of enabling the Resource Timing APIs. However, I'll note that I see this API as part of the diagnostic side of WebKit, just like the Web Inspector debugger. In the case of the Web Inspector today, it requires explicit user consent to enable the feature - you need to perform a UI gesture to open the debugger (hot key, menu item, etc). Besides Resource Timing and Navigation Timing, hopefully in the near future, all our WebKits will have remote debugging enabled: http://www.webkit.org/blog/1620/webkit-remote-debugging/ So there's another case where we will need some kind of explicit user consent to enable the feature. I wonder if we could lump all this stuff together into a single diagnostic mode run-time guard. Turn it on, all the diagnostic, perhaps dangerous, API and capability is available. Turn it off - and it's off by default - and dangerous API and capability is not available. -- 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] New Feature - Resource Timing
On 5/20/11 12:46 PM, Alexey Proskuryakov wrote: What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them. This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere. -- 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] Verifying changes to build.webkit.org-config/master.cfg locally
If someone does that, seems we should turn it into a script in Tools/Scripts
for easy testing of buildbot! :)
On Mon, May 23, 2011 at 10:58 AM, Adam Roben aro...@apple.com wrote:
On May 20, 2011, at 8:22 PM, Dmitry Lomov wrote:
I am trying to make run-api-tests run at build time.
I wonder what is the right way to verify my changes locally (aka what do I
run to simulate build on bots locally?)
Here are instructions I was given by Bill Siegrist (_wms) a while back:
The basic steps to making a test version of build.webkit.org are:
1. Install stuff on a Mac (I use MacPorts for this, but using the built-in
easy_install for Python 2.6 on SnowLeopard should work too)
a) buildbot (port name: buildbot)
b) simplejson (port name: py26-simplejson)
2. Create a master by doing: buildbot create-master
/path/to/an/empty/directory
3. Get the files from the webkit svn repo (master.cfg and config.json). Put
them in your buildbot master directory from when you did `buildbot
create-master` in step 2.
4. create a passwords.json in the master directory with a dictionary of
slavename-password keys like: { apple-test-slave: thepassword, }
5. Follow normal buildbot documents to start the master (run `buildbot
start` in the master directory). The master website should be visible on
port 8710.
6. Send changes using the buildbot tool. The following uses a lot of bogus
data. All that should matter for testing scheduling/filtering is the branch
value given to the -b option.
$ buildbot sendchange -b branches/foo -r 12345 -u someuser
--master=localhost:17000 -m commit message -R therepo somefiles
Note that builds will not start until there have been no changes for 45
seconds (this is set in config.json via treeStableTimer).
See also: http://buildbot.net/buildbot/docs/current/
-Adam
___
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] Early deletion of DocumentLoader instances
Hey there, While working on the EFL port, I've noticed that sometimes a FrameLoader's DocumentLoader ends up being deleted too early (FrameLoader::setDocumentLoader causes the current DocumentLoader to be deref'ed and freed), in the sense that later on Document::explicitClose tries to access this DocumentLoader instance that has already been freed, causing a crash. I couldn't find any abnormal behaviour that could deref the DocumentLoaders more than they should have been. Are there any recommended places where I should look to check what's going on? -- Raphael Kubo da Costa ProFUSION embedded systems http://profusion.mobi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Early deletion of DocumentLoader instances
On May 23, 2011, at 1:34 PM, Raphael Kubo da Costa wrote: While working on the EFL port, I've noticed that sometimes a FrameLoader's DocumentLoader ends up being deleted too early (FrameLoader::setDocumentLoader causes the current DocumentLoader to be deref'ed and freed), in the sense that later on Document::explicitClose tries to access this DocumentLoader instance that has already been freed, causing a crash. This looks like a basic design problem. The document has a pointer to the document loader, and keeps that pointer even after the document loader has been destroyed. That is a broken design. Also, there is a Document::setDocumentLoader function, but nobody ever calls it. What we need are some test cases showing problems caused by this mistake that we can use as regression tests; then we should fix it by making some better relationship between the Document and DocumentLoader that guarantees we won’t have a dangling pointer. Either reference counting to keep the object alive, or code to zero out the pointer at some point before the object is deleted. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Mac-EWS is down until further notice
***Mac-EWS machines down until further notice.*** I'm sorry for the unexpected outage. I may be able to bring them up as soon as next week. If someone else would like to try running a mac-ews, the instructions remain the same as always: 1) Tools/Scripts/webkit-patch mac-ews 2) There is no step 2. If you want to set up a long-running EWS instance (which is robust against python code changes, etc.) you would instead run: Tools/EWSTools/start-queue.sh mac-ews my-creative-ews-bot-name However (due to start-queue.sh being rather dumb), this will require that you place your checkout at /mnt/git/webkit-mac-ews, or at least symlink it from there. You're also welcome to hack start-queue to make it smarter.) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] New Feature Flag Proposal: INPUT_COLOR
Hi webkit-dev, I just wanted to notify everyone that I will be adding a new feature flag, INPUT_COLOR. http://webkit.org/b/61273 This flag will enable input type=color I need this flag because the color picker UI needs to be implemented individually for each platform, and it is going to take some time. Also the current text field implementation will be disabled. This is to avoid feature detection so that web pages can fall back to JS color pickers. Thanks! Keishi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature Flag Proposal: INPUT_COLOR
On Mon, May 23, 2011 at 9:57 PM, Keishi Hattori kei...@webkit.org wrote: Hi webkit-dev, I just wanted to notify everyone that I will be adding a new feature flag, INPUT_COLOR. http://webkit.org/b/61273 This flag will enable input type=color I need this flag because the color picker UI needs to be implemented individually for each platform, and it is going to take some time. If you need any help on the Qt side feel free to ping me (darktears). Also the current text field implementation will be disabled. This is to avoid feature detection so that web pages can fall back to JS color pickers. Thanks! Keishi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard Software Engineer INdT Recife Brazil ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature Flag Proposal: INPUT_COLOR
Exciting times! On May 23, 2011 8:57 PM, Keishi Hattori kei...@webkit.org wrote: Hi webkit-dev, I just wanted to notify everyone that I will be adding a new feature flag, INPUT_COLOR. http://webkit.org/b/61273 This flag will enable input type=color I need this flag because the color picker UI needs to be implemented individually for each platform, and it is going to take some time. Also the current text field implementation will be disabled. This is to avoid feature detection so that web pages can fall back to JS color pickers. Thanks! Keishi ___ 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] Question on font property value inherit in HTML Canvas
Hi, I was just thinking if anyone could provide me some help for the issue mentioned below so that I can proceed further to resolve this. If you need further info/clarification, please let me know, I would be glad to provide more details. Thanks, Rahaman. On Fri, May 20, 2011 at 6:05 PM, Mustafizur Rahaman mustaf.h...@gmail.comwrote: Hi, I am analyzing the following issue https://bugs.webkit.org/show_bug.cgi?id=48575 (the attachment in the issue description contains multiple issues) I was particularly looking into * http://w3c-test.org/html/tests/approved/canvas/canvas_text_font_001.htm*(Test-case passes in FF but NOT working in Safari(5.0.3)/Winlauncher setup [r86221]) After going through the HTML5 Canvas spec ( http://www.w3.org/TR/2dcontext/#dom-context-2d-font), my understanding is that if any of inherit/initial/default are used in the font property assignment statement (e.g., 20px inherit OR inherit 20px), then it must ignore the font value assignment continue with the previous font value assigned. This is in contrast to the CSS2.1 specification which allows the usage of inherit (The values initial/default are reserved for future use). Is this understanding correct? After debugging CSSParser CSSGrammer.y I have found that: = for normal HTML/CSS the code flows through CSSParser::parseSheet() = cssyyparse() = CSSParser::parseValue() = for HTML5 Canvas, the code flows through CSSParser::parseDeclaration() = cssyyparse() = CSSParser::parseValue() In the CSSParser::parseValue(), the handling is same for normal HTML/CSS as well as for HTML5 Canvas, i.e., it is handling the inherit in the same way. However, if my understanding as mentioned above is correct, the handling within the parser should be different (reason: CSS2.1 spec the HTML Canvas 2D Context spec expects inherit to be handled differently). Can somebody help share thoughts/perspective on this... Thanks, Rahaman ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
