Re: [webkit-dev] Top 100 sites browsing tests proprosal
But are you planning to run test builds against live websites? That's not very polite on people's servers (i certainly wouldn't like anyone stress-testing my own servers for their benefit). And like some other people said, tests that rely on network randomness are not very reliable indicators of anything. I think he is planning to have a local copy of those websites, and its public interface will only be run tests like the EWS system. As far as I know that is possible way to avoid copyright issues. Thanks for the explanation Sergio, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top 100 sites browsing tests proprosal
On Mon, Jan 23, 2012 at 2:14 AM, Aaron Boodman a...@google.com wrote: On Sun, Jan 22, 2012 at 12:00 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen kbal...@webkit.org wrote: As the goal is to test real world use case I think it can be even better to simply load the sites from network. I see only two disadvantage of that but neither of them are blocker: 1. The sites changing over time. However, as this would be a smoke test (and not a regtest or a perf test) I don't think it's a big problem 2. Cannot test offline. Well, I don't think taking part in the development of WebKit is possible without being online anyway :) Do you see other disadvantages? Loading over a network connection is slower. Especially if you expect developers to run these tests locally, this could be a serious time sink. Loading real-world sites over a real network connection adds numerous possible flakiness/failure sources. I would never use something like this as part of an automated system. Arguably, it's not kind to site authors to constantly reload their real sites as part of an automated testing program. From experience using offline copies of popular sites for testing in both Firefox and Chrome, I strongly suggest you go the offline route. How would you capture and replay websites offline? This is non-trivial. Very much non-trivial ;) Depending on which route you end up deciding to take, you might also want to consider http://code.google.com/p/web-page-replay/ which scrapes and replays web pages without being tied to a specific browser. It does some fuzzy request matching and injects a bit of JS to ensure deterministic playback w.r.t the issues Aaron mentions here. Without something like that, it is surprisingly difficult to replay real-world web pages. In Chromium, we have --record-mode and --playback-mode flags for this use case. They put the cache, cookie jar, and some other components into a special mode where everything is aggressively captured and replayed without going to the net. In the case of Firefox, I believe someone at one time implemented a Firefox extension that rewrote pages to capture resources and use local references. Since most websites are not redistributable, it seems like you need some code like Chromium's or Firefox's in WebKit in order to make this proposal work with offline data. - a ___ 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] Top 100 sites browsing tests proprosal
I don't think this needs to be done by every developer on every checkin. It could be done by the buildbots daily, and whenever a crash is found, somebody would need to find the cause and turn it into a real regression test for later. The fact that the web sites change over time isn't important because the cause of the failure would get a separate test. (It would still be a good idea to save the site locally so that the exact version can be replayed after a crash, but this would be a temporary copy which is thrown away as soon as the test succeeds.) From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Peter Kasting Sent: Sunday, January 22, 2012 3:01 PM To: Balazs Kelemen Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Top 100 sites browsing tests proprosal On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen kbal...@webkit.orgmailto:kbal...@webkit.org wrote: As the goal is to test real world use case I think it can be even better to simply load the sites from network. I see only two disadvantage of that but neither of them are blocker: 1. The sites changing over time. However, as this would be a smoke test (and not a regtest or a perf test) I don't think it's a big problem 2. Cannot test offline. Well, I don't think taking part in the development of WebKit is possible without being online anyway :) Do you see other disadvantages? Loading over a network connection is slower. Especially if you expect developers to run these tests locally, this could be a serious time sink. Loading real-world sites over a real network connection adds numerous possible flakiness/failure sources. I would never use something like this as part of an automated system. Arguably, it's not kind to site authors to constantly reload their real sites as part of an automated testing program. From experience using offline copies of popular sites for testing in both Firefox and Chrome, I strongly suggest you go the offline route. PK - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top 100 sites browsing tests proprosal
People run test builds against live servers by hand all the time. As long as we don't do it too often, I don't see a problem. Especially as this list would be taken from a list of top 100 web sites, which presumably would each be big enough to handle the traffic. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Pablo Flouret Sent: Monday, January 23, 2012 2:45 AM To: Sergio Villar Senin Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Top 100 sites browsing tests proprosal On Sun, Jan 22, 2012 at 11:37 PM, Sergio Villar Senin svil...@igalia.com wrote: En 22/01/12 20:24, Thiago Marcos P. Santos escribiu: On Sun, Jan 22, 2012 at 1:06 PM, Pablo Flouret pab...@motorola.com Maybe instead of storing a local snapshot (assuming you need static content for the tests), you can use a online snapshot of a top 100 website from http://web.archive.org for validation. Not sure if by doing that you can face the same copyright issues, and... IANAL. :) Maybe I didn't explain myself correctly, but my idea was not to store snapshots in the WebKit SVN, it will not be a developer's tool like the Layout tests or ref tests but something that will act similar to the EWS. You will not be supposed to run those tests manually, bots will. That's the reason why I was not understanding the copyright concerns. I know that they won't work offline, but again their purpouse will not be to detect regressions ASAP as the layout tests, but to complement them. But are you planning to run test builds against live websites? That's not very polite on people's servers (i certainly wouldn't like anyone stress-testing my own servers for their benefit). And like some other people said, tests that rely on network randomness are not very reliable indicators of anything. -- pablo flouret ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Commit-queue
Hi All, I'm seeing the commit-queue bot http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02 consistently rebooting about every hour. I know I'm not the only one with a patch that has commit-queue+ waiting for this to be resolved. Can someone look into this failure. The last commit-queue patch that I see was from Saturday night and even the bot confirms that the last PASS was 1 day 15 hours ago. Thanks, Konrad - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit-queue
On Mon, Jan 23, 2012 at 11:07 AM, Konrad Piascik kpias...@rim.com wrote: I'm seeing the commit-queue bot http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02 consistently rebooting about every hour. I know I'm not the only one with a patch that has commit-queue+ waiting for this to be resolved. Can someone look into this failure. The last commit-queue patch that I see was from Saturday night and even the bot confirms that the last PASS was 1 day 15 hours ago. I'll look into it. Thanks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit-queue
On Mon, Jan 23, 2012 at 11:12 AM, Adam Barth aba...@webkit.org wrote: On Mon, Jan 23, 2012 at 11:07 AM, Konrad Piascik kpias...@rim.com wrote: I'm seeing the commit-queue bot http://webkit-commit-queue.appspot.com/queue-status/commit-queue/bots/ec2-cq-02 consistently rebooting about every hour. I know I'm not the only one with a patch that has commit-queue+ waiting for this to be resolved. Can someone look into this failure. The last commit-queue patch that I see was from Saturday night and even the bot confirms that the last PASS was 1 day 15 hours ago. I'll look into it. Thanks. I believe I've fixed the issue. Thanks again, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ProgressEvents for Images
On 17/01/2012, at 10:41 AM, Bear Travis wrote: A group of us at Adobe has been looking into adding support for ProgressEvents to images. The overall goal is to simplify image download progress reporting by supporting roughly the same progress events as XHR and the File API for image elements. For example one could connect an image to a progress element like this: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Dean We're working on a prototype implementation for WebKit and have filed a bug that explains what we're up to in a little more detail: https://bugs.webkit.org/show_bug.cgi?id=76102 It's probably worth pointing out that the beforeload event, which is currently under discussion, addresses a different use case. Our proposal is intended to enable applications to give the user feedback about image download progress, it's not intended to enable security or efficiency by preemptively blocking or transforming image downloads. We'd appreciate feedback on this proposal. ___ 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] Announcement of Coding Style Change in WebKit EFL port
Ok, I'm going to file a bug for style checker. And, add you guys to CC. :-) Thank you, Gyuyoung. On Sat, Dec 31, 2011 at 7:09 AM, David Levin le...@google.com wrote: Feel free to patch the style checker as appropriate. I suspect there may be some changes needed here: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checker.py#L180 Best wishes, dave On Tue, Dec 27, 2011 at 11:54 PM, Gyuyoung Kim gyuyoung@samsung.comwrote: Hello WebKit folks, As you may know, I have changed the coding style of EFL port via Bug 68209. This is to eliminate unnecessary difficulties that reviewers have experienced when they review EFL bugs, due to EFL specific coding style. Bug 68209 - [EFL] Change WebKit EFL coding style (https://bugs.webkit.org/show_bug.cgi?id=68209) Major changes are as below, 1. Use full variable name instead of abbreviation name. 2. Use standard boolean type instead of EFL boolean type. 3. Place '*' operator immediately after the data type. (For example, use char* userAgent. instead of char *userAgent.) 4. Use C++ type casting instead of C type casting. 5. Remove void parameter from internal functions. 6. Use camelCase instead of underbar(_) in variable names. I made a wiki page for this rule. I will update this page whenever EFL port coding style guide is changed. (http://trac.webkit.org/wiki/EFLWebKitCodingStyle) To sum up, EFL port adheres to WebKit coding style except for public header from now. (Because public header is used by EFL applications, public header will continue to follow the coding style rule of EFL.) We hope that reviewing of EFL port patches will be much easier after this change. Happy new year !! Regards, Gyuyoung Kim. ___ 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] Announcement of Coding Style Change in WebKit EFL port
Hello Dave, As I mentioned in previous email, I couldn't change the coding style of public header file. So, EFL port still has naming violation regarding EFL coding style in public header. It also influences on .cpp files. For example, function naming, EFL data type. So, I only could remove *whitespace/declaration* style rule from it. Bug 75424 - [EFL] Remove whitespace/declaration style exception. https://bugs.webkit.org/show_bug.cgi?id=75424 Cheers, Gyuyoung. On Mon, Jan 2, 2012 at 10:43 AM, Gyuyoung Kim gyuyo...@gmail.com wrote: Ok, I'm going to file a bug for style checker. And, add you guys to CC. :-) Thank you, Gyuyoung. On Sat, Dec 31, 2011 at 7:09 AM, David Levin le...@google.com wrote: Feel free to patch the style checker as appropriate. I suspect there may be some changes needed here: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checker.py#L180 Best wishes, dave On Tue, Dec 27, 2011 at 11:54 PM, Gyuyoung Kim gyuyoung@samsung.comwrote: Hello WebKit folks, As you may know, I have changed the coding style of EFL port via Bug 68209. This is to eliminate unnecessary difficulties that reviewers have experienced when they review EFL bugs, due to EFL specific coding style. Bug 68209 - [EFL] Change WebKit EFL coding style (https://bugs.webkit.org/show_bug.cgi?id=68209) Major changes are as below, 1. Use full variable name instead of abbreviation name. 2. Use standard boolean type instead of EFL boolean type. 3. Place '*' operator immediately after the data type. (For example, use char* userAgent. instead of char *userAgent.) 4. Use C++ type casting instead of C type casting. 5. Remove void parameter from internal functions. 6. Use camelCase instead of underbar(_) in variable names. I made a wiki page for this rule. I will update this page whenever EFL port coding style guide is changed. (http://trac.webkit.org/wiki/EFLWebKitCodingStyle) To sum up, EFL port adheres to WebKit coding style except for public header from now. (Because public header is used by EFL applications, public header will continue to follow the coding style rule of EFL.) We hope that reviewing of EFL port patches will be much easier after this change. Happy new year !! Regards, Gyuyoung Kim. ___ 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] Asking for review by pinging bugs---another approach
In new port case, for example EFL port, we unfortunately don't have special reviewer for our port yet. So, we have requested to review on IRC after finishing our informal review. If we only ask some reviewers to review, the reviewers will have too many review burden. We have found proper reviewers on IRC in order to avoid this. In this case, is there better way to find proper reviewer for EFL port patch ? Happy new year !! On Thu, Jan 5, 2012 at 5:03 PM, Andreas Kling kl...@webkit.org wrote: On Thu, Jan 5, 2012 at 7:49 AM, Adam Barth aba...@webkit.org wrote: Not to pick on anyone in particular, but when reading bugmail I occasionally see messages like pinging for review. I review a lot of patches, but I don't find these messages particularly helpful because I don't know whether I'm supposed to review the patch. Another approach that might work better for you is to address your comment at someone in particular. For example, if the message says Adam, can you please review this patch?, then there's a pretty good chance I'll click through and try to answer your question. If you're unsure who to ask for review, one approach is to look at the svn log for the files you're changing and see who has written/reviewed patches for those files recently. You can also ask folks who've been around the project for a while to suggest someone. True that. You can also find reviewers for a particular area here on the WebKit Team wiki page: http://trac.webkit.org/wiki/WebKit%20Team (and I encourage people to keep their entry up-to-date.) -Kling ___ 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] Asking for review by pinging bugs---another approach
In new port case, for example EFL port, we unfortunately don't have special reviewer for our port yet. So, we have requested to review on IRC after finishing our informal review. If we only ask some reviewers to review, the reviewers will have too many review burden. We have found proper reviewers on IRC in order to avoid this. In this case, is there better way to find proper reviewer for EFL port patch ? - gyuyoung On Fri, Jan 6, 2012 at 3:40 AM, Adam Barth aba...@webkit.org wrote: Sure. Feel free to add that feature. Obviously we don't want to force people to use it, but it might become popular. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port
Hello WebKit folks. It looks that the result of layout test for EFL port needs rebaseline because of 101343. The revision modified line spacing of font in SimpleFontDataFreeType.cpp, and it seems that the existing layout test result of EFL port was influenced by it. ( http://trac.webkit.org/changeset/101343) 3,936 test cases are failed after the revision (101343). * EFL port's layout test result with r101343 = Results: 16139/27915 tests passed (57.8%) = Tests to be fixed (11776): 4423 text diff mismatch (37.6%) 9 image mismatch ( 0.1%) 7344 skipped (62.4%) * EFL port's layout test Result without r101343 = Results: 20074/27915 tests passed (71.9%) = Tests to be fixed (7841): 1 test timed out ( 0.0%) 487 text diff mismatch ( 6.2%) 9 image mismatch ( 0.1%) 7344 skipped (93.7%) It looks GTK port also did rebaseline due to the revision. - http://trac.webkit.org/changeset/101354 - http://trac.webkit.org/changeset/101352 - http://trac.webkit.org/changeset/101351 - And so on. I think EFL port also needs to do rebaseline for layout test result. GTK port did rebaseline without review because patch is too huge. Is there any processes for rebaseline ? - gyuyoung ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port
On Mon, Jan 16, 2012 at 12:02 AM, Gyuyoung Kim gyuyo...@gmail.com wrote: Hello WebKit folks. It looks that the result of layout test for EFL port needs rebaseline because of 101343. The revision modified line spacing of font in SimpleFontDataFreeType.cpp, and it seems that the existing layout test result of EFL port was influenced by it. ( http://trac.webkit.org/changeset/101343) 3,936 test cases are failed after the revision (101343). * EFL port's layout test result with r101343 = Results: 16139/27915 tests passed (57.8%) = Tests to be fixed (11776): 4423 text diff mismatch (37.6%) 9 image mismatch ( 0.1%) 7344 skipped (62.4%) * EFL port's layout test Result without r101343 = Results: 20074/27915 tests passed (71.9%) = Tests to be fixed (7841): 1 test timed out ( 0.0%) 487 text diff mismatch ( 6.2%) 9 image mismatch ( 0.1%) 7344 skipped (93.7%) It looks GTK port also did rebaseline due to the revision. - http://trac.webkit.org/changeset/101354 - http://trac.webkit.org/changeset/101352 - http://trac.webkit.org/changeset/101351 - And so on. I think EFL port also needs to do rebaseline for layout test result. GTK port did rebaseline without review because patch is too huge. Is there any processes for rebaseline ? In Chromium, rebaselines are nearly always landed by Chromium committers without review. If there is some doubt on whether a rebaseline is correct or not it's expected that the committer will check with the appropriate party, but we don't require the full review process. I'd expect other ports follow a similar guideline for their own baselines. - James - gyuyoung ___ 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] ProgressEvents for Images
On 1/23/12 2:55 PM, Dean Jackson wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Seems like this would need to follow CORS. Even disclosing the file size is going too far for cross-domain without CORS. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ProgressEvents for Images
Hi Dean, Thank you for the feedback. We have floated the idea to the WHATWG mailing list, and are attempting to build enough support to draft a proper proposal. -Bear On 1/23/12 2:55 PM, Dean Jackson d...@apple.com wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: A group of us at Adobe has been looking into adding support for ProgressEvents to images. The overall goal is to simplify image download progress reporting by supporting roughly the same progress events as XHR and the File API for image elements. For example one could connect an image to a progress element like this: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Dean We're working on a prototype implementation for WebKit and have filed a bug that explains what we're up to in a little more detail: https://bugs.webkit.org/show_bug.cgi?id=76102 It's probably worth pointing out that the beforeload event, which is currently under discussion, addresses a different use case. Our proposal is intended to enable applications to give the user feedback about image download progress, it's not intended to enable security or efficiency by preemptively blocking or transforming image downloads. We'd appreciate feedback on this proposal. ___ 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] ProgressEvents for Images
There's a brief discussion of the cross-origin case in the ProgressEvents for Images WhatWG thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034362.htm l and the WebKit bug about this proposed feature: https://bugs.webkit.org/show_bug.cgi?id=76102 For cross-site images for which crossOrigin is not set, we'd proposed normalizing the loaded and size ProgressEvent attributes: ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations. This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images. Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes. A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress. Normalization would set total to a constant like 1000, and loaded to a relatively correct value. The motivation for providing progress events in the cross origin case is applicaitons like image galleries, that just display a list of image URLs. Displaying (possibly normalized) download progress for images that will be displayed seems desirable. - Hans On 1/23/12 3:42 PM, Charles Pritchard ch...@jumis.com wrote: On 1/23/12 2:55 PM, Dean Jackson wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Seems like this would need to follow CORS. Even disclosing the file size is going too far for cross-domain without CORS. -Charles ___ 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] ProgressEvents for Images
On Mon, Jan 23, 2012 at 4:02 PM, Hans Muller hmul...@adobe.com wrote: There's a brief discussion of the cross-origin case in the ProgressEvents for Images WhatWG thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-January/034362.htm l and the WebKit bug about this proposed feature: https://bugs.webkit.org/show_bug.cgi?id=76102 For cross-site images for which crossOrigin is not set, we'd proposed normalizing the loaded and size ProgressEvent attributes: ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations. This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images. Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes. A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress. Normalization would set total to a constant like 1000, and loaded to a relatively correct value. The motivation for providing progress events in the cross origin case is applicaitons like image galleries, that just display a list of image URLs. Displaying (possibly normalized) download progress for images that will be displayed seems desirable. Using zero values sounds safer than normalized values because an attacker might be able to back out the real values from the normalized values by taking into account things like the default packet size. Adam On 1/23/12 3:42 PM, Charles Pritchard ch...@jumis.com wrote: On 1/23/12 2:55 PM, Dean Jackson wrote: On 17/01/2012, at 10:41 AM, Bear Travis wrote: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. I think this would be extremely useful. It would require a proposal to W3C or WHATWG though. Seems like this would need to follow CORS. Even disclosing the file size is going too far for cross-domain without CORS. -Charles ___ 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
