Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

> 22 янв. 2015 г., в 17:57, Darin Adler написал(а): > > What about the test I cited? > > svg/css/svg-resource-fragment-identifier-img-src.html This particular test is buggy - it is a hidpi test, so it dumps results as a 1600x1200 image, but its -expected.html is not hidpi, and is dumped as 80

Re: [webkit-dev] run-webkit-tests question; hashes when comparing ref test output

22 янв. 2015 г., в 11:30, Simon Fraser написал(а): > This happens when the expected and actual images are very close, but not > identical. ImageDiff has some built-in rounding that effectively acts as a > small tolerance, so the hashes are different, but ImageDiff incorrectly says > the image

Re: [webkit-dev] review times

03 дек. 2014 г., в 2:32, Daniel Lazarenko написал(а): > Whatsoever it would be nice find a new reviewer for my patch. Does anybody > want to take it? Just to be clear about this part, the reviewer should not be just "anybody". This patch is part of an effort to implement a new feature in WebK

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

> 24 нояб. 2014 г., в 1:28, Antti Koivisto написал(а): > > I don't think this is really 32bit vs 64bit platform issue. The vast majority > of 64bit systems our users have (that is iOS devices) can't use memory > buffers sized anywhere near the 32bit limit even in theory. Also when using > Vec

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

SmallVector and Vector seem reasonable to me. I think that this is the right nomenclature - using limited size vectors should be a conscious choice. Even SmallVector should probably have a size_t API, so that we could centralize magnitude checks. What do you think? - Alexey 20 нояб. 2014 г.,

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

20 нояб. 2014 г., в 10:45, Filip Pizlo написал(а): >> - uint64_t everywhere. This way, we'll solve practical problems with large >> resources once and for all. Also, this may prove to be necessary to solve >> even YouTube/Google Drive uploads, I do not know that yet. > > How does this solve t

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

19 нояб. 2014 г., в 14:58, Alexey Proskuryakov написал(а): > These and related uses are all over the place - see also Vectors in > FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, > plug-in code that loads from network, SharedBuffer etc. Another way to sa

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

19 нояб. 2014 г., в 13:58, Filip Pizlo написал(а): >> With Vector though, I don't know how we would differentiate code paths that >> need large allocations from ones that don't. Nearly anything that is exposed >> as a JS API or deals with external world can hit sizes over 4Gb. That's not >> o

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

wouldn't even be a primitive type > but a class that carefully checked that you never overflowed 53 bits. > > -Filip > > >> On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov wrote: >> >> >> This is not exactly about Vector, but if one uses

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

This is not exactly about Vector, but if one uses FileReader.prototype.readAsArrayBuffer() on a large file, I think that it overflows ArrayBuffer. WebKit actually crashes when uploading multi-gigabyte files to YouTube, Google Drive and other similar services, although I haven't checked whether

Re: [webkit-dev] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

The bug got actually created despite the error, . - Alexey 24 окт. 2014 г., в 3:54, Philippe Normand написал(а): > Hi! > > I'm using the XML-RPC API (via git-bz) and when attaching a patch to a > bug I get the following error: > > There was

Re: [webkit-dev] New EWS status bubbles in Bugzilla

On 30 сент. 2014 г., at 0:56, Carlos Garcia Campos wrote: >> Thinking about this now, we could replace bubbles with text when no >> queue has results (i.e. at least one queue has failed to apply, and >> those that didn't still haven't started processing - we can reasonably >> expect that they wi

Re: [webkit-dev] New EWS status bubbles in Bugzilla

29 сент. 2014 г., в 23:12, Carlos Garcia Campos написал(а): >> Please try it out, and let me know if something breaks, or is not as >> good as it could be! > > Looks great! thanks. I've noticed that now we use red also for patches > that don't apply. I liked that there was a different color fo

[webkit-dev] New EWS status bubbles in Bugzilla

Hi, WebKit Bugzilla has new EWS status bubbles now, which will hopefully make it more clear what's going on with a patch. Mysterious yellow bubbles that could mean anything were eliminated, and most importantly, there is now detailed information presented on hover: Please try it out, and let

[webkit-dev] Fooling with EWS and commit queue

Hi, I started making changes to the logic of EWS and commit queue, please e-mail me if something breaks, or even if something begins to behave more strangely than it did before. - Alexey ___ webkit-dev mailing list webkit-dev@lists.webkit.org https:/

Re: [webkit-dev] DOMWindow::isCurrentlyDisplayedInFrame does not forbid PostMessageTimer for subframe

Hi! Could you please file a bug at bugs.webkit.org? If you have a reproducible test case where any bad behavior happens, that would be most useful. I think that the proposed fix would break a case where we currently match Firefox: main.html: - Click function f() { var c

[webkit-dev] WebKit Dashboard metrics

Hi, You may have noticed some patches for WebKit Dashboard metrics page landed recently. The page is now live at . It's a tool that collects historical information from Buildbot and answers these questions: - How much of the time did trunk build

Re: [webkit-dev] WebKit2 EWS bots are sick

25 авг. 2014 г., в 1:54, Benjamin Poulain написал(а): > It looks like the WebKit2 EWS bots are having a bad time. They keep > timing out on a bunch of tests. Can anyone restart them? The bots restart themselves frequently. Looks like there must be a real problem that makes them fail - I briefl

Re: [webkit-dev] Mac WK2 EWS bots having issues

30 июля 2014 г., в 11:17, Alexey Proskuryakov написал(а): > https://bugs.webkit.org/show_bug.cgi?id=135418 > media/track/add-and-remove-track.html and media/media-fragments/TC0001.html > are flaky on Mac WK2 EWS, asserting under > TestRunner::removeAllWebNotificationPermissions

Re: [webkit-dev] Mac WK2 EWS bots having issues

30 июля 2014 г., в 3:16, Osztrogonác Csaba написал(а): > You can check the SPAM history with this bugzilla query: http://goo.gl/qepg2l > (30 days history) Thank you for posting this. What's interesting is that right now, the latest result is accurate, the patch actually breaks a test. I look

Re: [webkit-dev] Mac WK2 EWS bots having issues

30 июля 2014 г., в 3:16, Osztrogonác Csaba написал(а): > If there is no volunteer for fixing it in the near future, > I'm going to propose a patch making the Mac WK2 EWS not > comment bugzilla and set cq- for random patches. I've been already looking into this, and fixed some issues. Admittedly

Re: [webkit-dev] Mixed content checking

23 июля 2014 г., в 17:08, Michael Catanzaro написал(а): > One problem with these settings is that frames are treated as mixed > passive content rather than mixed active content. For the WebKitGTK+ API > I want frames to be treated as active content, which is what most major > browsers currently

Re: [webkit-dev] Mac WK2 EWS bots having issues

Some of the bugs tracking the issues are and . - Alexey 14 июля 2014 г., в 7:23, Osztrogonác Csaba написал(а): > Hi, > > It seems the Mac WK2 EWS bots are very flakey nowadays, they set cq- >

Re: [webkit-dev] Comment on the bug & email author/reviewer before reverting a patch

(re-sent from correct address) 11 июля 2014 г., в 3:59, Maciej Stachowiak написал(а): > So it seems like the extra request for people using “webkitbot rollout” is to > add diagnostic information to the rollout bug, and wait a reasonable period > before cq+ing it. Is that something everyone cou

Re: [webkit-dev] Adding flag to optionally run check-webkit-style as part of prepare-Changelog and svn-create-patch

matting of existing code, which is not always appropriate. So, refusing to create a ChangeLog unless I disable the style checker would be quite annoying. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.we

Re: [webkit-dev] Heads-up: rollout changelog format change

file lists when the patch being rolled out isn't associated with a bug. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JavascriptCore API: Typed arrays

sion. https://bugs.webkit.org/show_bug.cgi?id=120112 is the bug that tracks adding such an API. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EWS doesn't lie!

ression tests in release mode. Other bots only verify that the patch builds, and don't run tests. No bots use debug mode as far as I know, so debug-only build failures and assertions will not be detected. Please run tests locally to catch as many of those as possibl

Re: [webkit-dev] EFL EWS Bot output

an extension and that has binary data in it, so it overrides the type. Another solution would be for webkitpy or webkit-queues to automagically strip escape sequences from the output. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

The latter might be best, as it also gives some control over whether to get pinged - keep the bug open if you care, close it if it's not urgent, and you cannot afford distraction now. I filed https://bugs.webkit.org/show_bug.cgi?id=127203 about this. - WBR, Alexey Proskuryakov 16 янв. 2

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

15 янв. 2014 г., в 23:02, Ryosuke Niwa написал(а): > I think that it's good to try not dumping build failures into comments right > away, and to see what happens. > > As for not showing style bot failures, it seems almost certain that this will > make them substantially more annoying to work

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

e the workflow for patch author and reviewer to deal with style bot warnings when they are not inline? Manually finding relevant lines by number can't work. I agree with Tim that dumping all tested paths along with style warnings is silly. How hard would it be it to get rid of that? - W

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

+1 This is blocked on improving Bugzilla EWS bubbles, making it humanly possible to find out without a comment which tests regressed. - WBR, Alexey Proskuryakov 15 янв. 2014 г., в 19:54, Sam Weinig написал(а): > Hi Everyone, > > I am becoming increasingly annoyed by the comment

Re: [webkit-dev] Apple Mac EWS 10.9 upgrade?

different version of the OS. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

ringFunction(); These lines will be visible in the patch, and a super careful reviewer could catch it. Overall, it would strain reviewers more, I think. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

le tend to work on bugs in many areas. > Thoughts? The latest set of rules proposed by Geoff looks pretty good to me. It would be great to make it a formal requirement. We can always add to it later if things get annoying. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

e.isolatedCopy()); if (iter == m_nameToIdentifierMap.end()) return false; - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Test flakiness.

ity tests with "--child-processes=1 --verbose" options, and to start bisecting if that makes the issue reliable. Another useful approach is to make the tests run multiple times with "--child-processes=1 --verbose —repeat-each=10"

[webkit-dev] New feature: SubtleCrypto

679 tracks this work. The spec is in <http://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html> - it's still under development, but is quickly gaining support from browser vendors. - WBR, Alexey Proskuryakov ___ webkit-dev ma

Re: [webkit-dev] Proposal: Use ICU in WebKit code

o whether we use ICU directly or through an abstraction layer. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EDITBUGS permission?

WebKit bug tracker is: b.l...@cablelabs.com Done. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Loading and unloading webkit, threading, AtomicString and crashes

ion time. To fix this issue, DEFINE_STATIC_LOCAL should be used. In a somewhat dated checkout I have on this machine, I found 5 instances of "static AtomicString" in WebCore, and none in WebKit/win. - WBR, Alexey Proskuryakov ___ webkit-dev mailing

Re: [webkit-dev] Proposed feature: Network Service Discovery

if you have any local media receivers", etc. ... "Would you like to install malware onto all networked printers in your office? Please click OK to get rid of this dialog, and finally start the browser game you want to play." - WBR, Alexey Proskuryakov __

[webkit-dev] Removing USE_WEBPROCESS_EVENT_SIMULATION

Would this cause trouble for any ports? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Some loading tests disturbance coming

mostly WebKit2 ones (as WebKit1 code is platform specific and so are many of the results). Please let me know if there are issues with my plan, or if you would like to coordinate timing. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev

Re: [webkit-dev] restricting the number of new windows created in response to a user gesture

. > Why do you want to add something even in the case no port would be interested? Per discussion in <https://bugs.webkit.org/show_bug.cgi?id=114021>, we appear interested in this. - WBR, Alexey Proskuryakov ___ webkit-dev mailing lis

Re: [webkit-dev] WebKit Wishes

d by this? Perhaps they can be solved on a case by case basis. I remember some prior discussions of this in Bugzilla, but my recollection is that things people tried to add did not fit network loading abstraction anyway. - WBR, Alexey Proskuryakov ___ w

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

gt; I'm not parsing your reply properly -- avoid trying what? A common > EXPORT macro that is set as appropriate by each port? Yes, you are parsing it correctly :) - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

gt;> > > I see. Some concrete examples would be helpful here (to me, at least). > What components and ports are we talking about, and what sorts of > symbols? I don't have concrete examples, and I don't know how big an effect on performance increasing the number of e

Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

be exported on some ports? The latter. I suspect that it's somewhat less of an issue for JavaScriptCore, because its exports are mostly used from cross-platform code. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Common build system (was Re: WebKit Wishes)

n already existing solution. To me personally, this means that Xcode project files need to be fully usable. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Breaking other ports

as the changeset has already been rolled out of chromium release branch before you first commented on bugs.webkit.org. I hope this explains the matter. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding Web MIDI API support to WebCore

ented/replaced with web apps. So, this could be a good feature not not add. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding Web MIDI API support to WebCore

ore is hopefully not an operating system that has to provide APIs for every peripheral a computer has. Or if it is now, then it needs to be structured a very different way - implementing APIs for everything from MIDI to OpenGL to HTTP to encryption in a monolithic project just doesn&#x

[webkit-dev] EWS commenting about ancient patches

On several occasions over the last few days, I noticed EWS commenting in bugs that didn't have any recent activity, e.g. <https://bugs.webkit.org/show_bug.cgi?id=87527>. Is EWS picking ancient patches, or is it posting comments to wrong bugs? - WBR, Alexey P

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

and the rest affects performance tests (we attempted to have regression tests for fixes that change asymptotic complexity of algorithms, and they were very flaky). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

cally modeled on user expectations - changing a preference is expected to change how your browser behaves, so it's OK for tests to depend on that. But visiting site A is not expected to affect behavior on site B, even though cache state was affected by site A. - WBR, Alexey Proskuryakov ___

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

project scale change - I think that this is a result of the desire to get green bots without doing real WebCore work to fix underlying bugs. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

the tree. I agree with Antti. Finding regressions is what tests are for, and it would be difficult to make enough explicit tests to compensate for such loss of coverage. It would certainly be very unfortunate to lose test coverage without even an attempt to compensate for that. - WBR, Alexey P

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

some kind of generic priority is not, on the other hand. Anyway, as Brady mentioned, this is not related to this refactoring. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Tips on why run-webkit-tests is not working for me?

pt to use "xcrun make" here, and installing command line utilities is a workaround. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?

efinition are the same (i.e. in .h files), as there is no other place one could discover parameter's meaning if it were unnamed. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Should we close the tree? (was: Re: the new TestExpectations syntax is landing soon)

Now tracked as <https://bugs.webkit.org/show_bug.cgi?id=97182>. I think that we should close the tree if resolving this takes any significant time. Not being able to see how exactly tests are failing on other platforms is unacceptable. - WBR, Alexey Proskuryakov 20.09.2012,

[webkit-dev] Bug numbers in TestExpectations

y ". Free form comments worked great for both cases in Skipped files. It appears that the rigid format that requires putting a bug URL is causing more harm than good in practice. I suggest making the URL optional. - WBR, Alexey Proskuryakov _

Re: [webkit-dev] Passing null or undefined object as input url for XMLHttpRequest open()

ese forever. Could you elaborate on why this seems incorrect to you? Generally speaking, special casing just null and undefined to bypass toString conversion would be unusual and surprising. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

will undoubtedly have this unimplemented for a long time. - WBR, Alexey Proskuryakov 08.08.2012, в 10:47, Ojan Vafai написал(а): > See https://bugs.webkit.org/show_bug.cgi?id=93195. > > media/W3C/video/networkState/networkState_during_progress.html and > media/video-poster-blocked-by-wil

Re: [webkit-dev] removing js-test-post.js WAS: Can we distinguish imported tests in LayoutTests/css3 ?

12.06.2012, в 10:51, Alexey Proskuryakov написал(а): >> I'm sympathetic to this argument. In this case, the only way it makes the >> tests more fragile is that it makes them depend on us firing the onload >> event. I feel like so many things would break if you break on

Re: [webkit-dev] removing js-test-post.js WAS: Can we distinguish imported tests in LayoutTests/css3 ?

de. This is > something we should encourage. I'm not sure what you mean by this. The make-new-script-test tool includes js-test-pre.js and js-test-post.js, and it's the only way to autogenerate the boilerplate that I'm aware of. - WBR, Alexey Proskuryakov __

Re: [webkit-dev] Can we distinguish imported tests in LayoutTests/css3 ?

x27;d question that "getting rid" of some boilerplate in autogenerated code is a worthy goal, given that it will make tests more fragile. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.or

Re: [webkit-dev] webkit2 with v8

t's a strength. The code is more hackable, tests are easier to maintain etc. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit2 with v8

pport::injectInternalsObject(context); #endif This is of course something non-Qt developers have to worry about, see e.g. <https://bugs.webkit.org/show_bug.cgi?id=87783#c14>. - WBR, Alexey Proskuryakov 31.05.2012, в 9:38, Balazs Kelemen написал(а): > I continued to work on this, more complete pat

Re: [webkit-dev] Using namespace std

g directive doesn't add a name to containing namespace, so you can always disambiguate later, unlike with using declaration, which can create unsolvable conflicts. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http:

Re: [webkit-dev] Default viewport value on WAP DTDs

ri too. I think that introduction of new doctype based modes should go through HTML5 first - if WebKit needs this, then other browsers need it, too. Also, it's not clear what the distinction between mobile and non-mobile is. Is Safari on an 11" MacBook Air a mobile browser? - WBR, Alex

[webkit-dev] Eliminate potential null pointer dereference?

ok nice: <http://trac.webkit.org/changeset/114678/trunk/Source/WebCore/css/CSSStyleSelector.cpp>. We should not try to confuse ourselves with unusual for loop forms, and there is no explanation at all of why these changes are needed. No regression tests either. - WBR

[webkit-dev] Contributor meeting hackathon: Move methods from layoutTestController

We're capturing ideas for which LayoutTestController methods could be moved to Internals here: <https://trac.webkit.org/wiki/Internals_Hackathon>. Even found some that are completely unused in tests! - WBR, Alexey Proskuryakov ___ webkit-

Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes

DashboardBackwardCompatibilityMode(). Due to high potential of site breakage, this seems worth a separate setting with pre-made plumbing for site-specific quirks, so that ports seeing release blocking regressions on important sites wouldn't have to undo

Re: [webkit-dev] Feature Announcement: Adding

working fine. But in this case, I can't see any benefit of landing tests first. The downside is quite material - it's much more difficult for reviewer of actual code change to see what test coverage is. Additional bug/commit noise has i

Re: [webkit-dev] PageCache and modularization (was Re: The Care and Feeding of WebCore Modules)

05.03.2012, в 11:29, Adam Barth написал(а): > For better or worse, Geolocation doesn't support suspend/resume > (yet?) <https://bugs.webkit.org/show_bug.cgi?id=43956> Pages that use Geolocation should be able to use the page cache - WBR, Al

Re: [webkit-dev] PageCache and modularization (was Re: The Care and Feeding of WebCore Modules)

7;s difficult to make something an ActiveDOMObjects without introducing subtle bugs. The automatic invocation of suspend/resume functions it provides comes at the cost of unpredictable order they are invoked in, and of very strict limitations on what these functions can do. - WBR, Alexey Proskur

Re: [webkit-dev] The Care and Feeding of WebCore Modules

eCache::canCachePageContainingThisFrame makes the code less hackable, and is likely to become a disadvantage. - WBR, Alexey Proskuryakov 29.02.2012, в 23:31, Maciej Stachowiak написал(а): > > Here's an update of my lists based on the notes from you, Adam and others: > > == Existing

Re: [webkit-dev] The Care and Feeding of WebCore Modules

tious features, but the direction should be that some of the code will be merged back into files like Window.idl if the feature ever matures, not the other way around. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.o

Re: [webkit-dev] The Care and Feeding of WebCore Modules

the new operator #endif The goal is to make hacking easier. Moving files to separate directories should be done as long as that helps to advance the goal, but not beyond that, even if we now have an entertaining tool in the form of supplemental interfaces that lets you go far beyond reasonable. - W

Re: [webkit-dev] WebKit modularization

ritten by Apple) NavigatorGeolocation.{h,cpp,idl} have Google as copyright holder, which may or may not be correct (I think it's Apple) NavigatorMediaStream.{h,cpp,idl} have Google as copyright holder, which may or may not be correct (I think it's Ericsson) DOMURLMedi

Re: [webkit-dev] WebKit modularization

t think that it's too much to ask one to go through patches in a specific area they reviewed recently. I'm deeply concerned about the way this refactoring is implemented - it doesn't have much of a meaningful purpose overall, and patches are revi

Re: [webkit-dev] Removing obsolete File attributes

d (second or third hand, without hard data), they are not effective. FWIW, this is what I'd expect - developers don't check console logs for sites they've delivered and were paid for long ago. I should point out that replacement standard attributes have been implemented in

Re: [webkit-dev] WebKit modularization

ore to DOM as it gets. 3) The moves don't respect original licenses - e.g. DOMWindowXML.idl is LGPL, while DOMWindow.idl is BSD. 4) More files means longer build times. I think that most of the patches landed under this umbrella should be reconsidered, and most immediately tho

[webkit-dev] Removing obsolete File attributes

te possible consequences of the removal for port specific content? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

instead. > We had almost the same discussion over 15 months ago. I recommend you read > the mailing list archives. I didn't ask for this discussion to be repeated. You kept asking about the right thing to do, and sending UTF-8 bytes is clearly the right and forward looking th

Re: [webkit-dev] Removing deprecatedFrameEncoding

C 5987 style encoding added as another legacy fallback) fit the bill if allowed to be on equal footing with the existing request for comments. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

See > <http://greenbytes.de/tech/tc2231/#attwithutf8fnplain>. So IE, Opera, and > Konqueror decode as ISO-8859-1. It works with servers and intermediaries. Internet infrastructure would not collapse if UTF-8 was sent in a response header. - WBR, Alexey Proskuryakov ___

Re: [webkit-dev] Removing deprecatedFrameEncoding

s. RFC 5987 style gobbledygook really has no purpose here, and only complicates life for implementors, site authors and admins alike. We know that it works in practice. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webk

Re: [webkit-dev] Removing deprecatedFrameEncoding

's a huge step forward. Will this be reflected in an update to RFC 6266? If we don't agree on that, I don't see the point of discussing one minuscule detail of a design which is entirely different from the RFC. - WBR, Alexey Proskuryakov ___

Re: [webkit-dev] Removing deprecatedFrameEncoding

e non-ASCII characters in Content-Disposition are not allowed at all. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

sed earlier in this thread, waiting for complaints is not very practical for this kind of bugs - for multiple reason, it often takes extremely long time until someone files a bug. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@li

Re: [webkit-dev] Removing deprecatedFrameEncoding

f the > referring page. At least not in this case. This regression has been fixed yesterday, WebKit nighties should use referring frame encoding again. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://l

Re: [webkit-dev] Removing deprecatedFrameEncoding

regression, and I didn't know about it before. Unfortunately, prior experience suggests that number of complaints is not a very helpful metric for internationalization bugs, for various reasons. - WBR, Alexey Proskuryakov ___ webkit-dev mailing

Re: [webkit-dev] Removing deprecatedFrameEncoding

ame. Or am I missing something? So > what default is left? The client's locale? Yes, someone broke that. I'm in the process of adding test coverage, and fixing the regression. Besides client locale, there is UTF-8. That's actually the preferred option, which gets tried first. On

Re: [webkit-dev] Removing deprecatedFrameEncoding

ork fine for them today. I do not think that there is enough potential benefit to offset that. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

one we should be following blindly. It's especially so in this case, where limitations on how non-ASCII bytes are interpreted do not solve any problem except for formal compatibility with some universally ignored text in RFC 2616. - WBR, Alexey P

Re: [webkit-dev] Removing deprecatedFrameEncoding

.60: Respects default encoding, but buggy for Russian primary language, picking a different encoding than what is used for page content (ISO-8859-5 instead of Windows-1251). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@

<    1   2   3   4   5   6   >