[webkit-dev] Upgrading the WebKitGTK+ 64-bit Debug build slave
Hello to all, Currently both WebKitGTK+ debug bots hosted at Igalia bots are being run in the same host. We will be moving the 64-bit one to a new machine and they will not share resources anymore, thus making the build cycle shorter. We plan to move the Buildbot installation to the new machine in some hours, more precisely on Saturday, June 5th around 12:30 CEST. It should take less than 1 hour. If this poses a problem for some reason, please let me know. Best regards, -- Adrian Perez Igalia - Free Software Engineering signature.asc Description: PGP signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ask for WTF introduction
There's an excellent doc on some of WTF's smart pointers: http://webkit.org/coding/RefPtr.html I'm interested to hear if there are any other references out there too. On Fri, Jun 4, 2010 at 7:45 PM, Eric Zhou wrote: > Hi all, > > Could anyone give me some references about WTF, like tutorials or > introduction? > > Thanks > > BR/Eric > > ___ > 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] ask for WTF introduction
Hi all, Could anyone give me some references about WTF, like tutorials or introduction? Thanks BR/Eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience
As promised, here is the bug to track this issue. https://bugs.webkit.org/show_bug.cgi?id=40197 Sorry about starting a new thread. I was not able to reply from the archive. On Fri, Jun 4, 2010 at 2:04 PM, Grace Kloba wrote: > We (Android) are also looking at this area. We are working on a patch. > Will file a bug and provide a patch for the feedback. > > thanks, > Grace > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. Joe -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Darin Adler Sent: Wednesday, June 02, 2010 1:03 PM To: Eric Seidel Cc: WebKit Development Subject: Re: [webkit-dev] Style question: static, protected,or public members On Jun 1, 2010, at 10:09 PM, Eric Seidel wrote: > Let me summarize to see if I understand what should be updated in the style guide/check-webkit-style: > > Class static member variables should have an s_ prefix. > Protected and public member variables should be disallowed. > Private member variables should have an m_ prefix. > Struct member variables should have no prefix. Yes, I think that's what we discussed. While I don't love the "s_" prefix, I didn't love the "m_" one either, and I got used to it. > What about global statics? Currently I believe most have no prefix. Some have "k" or "g". We didn't discuss global variables outside of a class. If we decided to start using a prefix, I'd suggest "g_" but I don't think we need one. What do other people think? -- Darin ___ 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] Proposal: Rect based HitTest for a better touch experience
We (Android) are also looking at this area. We are working on a patch. Will file a bug and provide a patch for the feedback. thanks, Grace ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
On Fri, Jun 4, 2010 at 11:15 AM, Peter Kasting wrote: > On Fri, Jun 4, 2010 at 11:11 AM, Darin Adler wrote: > >> If the two enum types are identical except for their names, then this >> doesn’t firewall the types at all. > > > It doesn't firewall the concepts (but then, it's hard for an embedding > layer to not transmit any concepts, as that's basically the point). It does > firewall the actual #includes, and thus provides source independence for the > embedder/a point where the WebKit side can be built as its own independent > DLL (if we want to). > > PK > Right. Insulating the embedder from WebCore headers is very important. It helps avoid accidental dependencies on more of WebCore than just simple constant values. I can imagine a tool that would parse a WebCore enum and convert it to a WebKit API equivalent, but that seems dangerous as it would mean that a WebCore change could change the API. I think it is better for API changes to be more explicit. I also agree with Peter that a case-switch translation would be no less work to maintain. Our use of compile-time asserts catches any drift between the enum values (with the exception of newly appended WebCore enum values). However, a case-switch translation may become necessary if a WebCore enum value were deleted. Then we'd need to make a decision between either deleting the corresponding API enum value or providing compatible support for it somehow. If we chose the latter, then the API enum and the WebCore enum would no longer be 1-1, so we'd need a case-switch translation to cope. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Oh this is purely JS memory use? Hmm ok, my original example wouldn't work, but I still think I could construct an attack. Let me think about it some more. dave On Jun 4, 2010, at 2:31 PM, James Robinson wrote: > How? Visited state information is not stored in the javascript heap (which > is what this object contains information about). > > - James > > On Fri, Jun 4, 2010 at 12:06 PM, David Hyatt wrote: > I'm fairly certain I could construct an attack on :visited history privacy > using this object. > > dave > > On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > >> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> >> Why is the continuous integration/buildbot use-case of limited utility? Or >> are you saying that Console.memory doesn't really support that use-case >> well? I think we want to make it as easy as possible for complex apps (e.g. >> email apps, mapping apps, etc.) to care about and monitor memory use. >> >> While I'm not convinced by the utility argument, I do buy the security >> argument. How would you feel about leaving the code in, but disabling it by >> default? Then it could be enabled by command-line or via a preference. >> >> That said, I'm OK with rolling back for now given that the code was >> committed without this discussion actually coming to a conclusion. >> >> Ojan >> ___ >> 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] On adding 'console.memory' API (and about the whole 'console' object.)
To get more specific, the style allocated for visited state is freed when you're an unvisited link to save memory (lots of memory), but it is not freed if you're visited. So there's a definite memory consumption difference. This memory difference would be magnified and obvious if you made 1 visited links vs. 1 unvisited links. We would have to deliberately consume megabytes more of memory just to prevent this attack if we keep this object in, and I just made the above fix to prevent a more than 4mb memory regression. Therefore I do not think memory use information is safe to expose, and this feature is not something we should be adding. dave (hy...@apple.com) On Jun 4, 2010, at 2:06 PM, David Hyatt wrote: > I'm fairly certain I could construct an attack on :visited history privacy > using this object. > > dave > > On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > >> On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> >> Why is the continuous integration/buildbot use-case of limited utility? Or >> are you saying that Console.memory doesn't really support that use-case >> well? I think we want to make it as easy as possible for complex apps (e.g. >> email apps, mapping apps, etc.) to care about and monitor memory use. >> >> While I'm not convinced by the utility argument, I do buy the security >> argument. How would you feel about leaving the code in, but disabling it by >> default? Then it could be enabled by command-line or via a preference. >> >> That said, I'm OK with rolling back for now given that the code was >> committed without this discussion actually coming to a conclusion. >> >> Ojan >> ___ >> 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] On adding 'console.memory' API (and about the whole 'console' object.)
How? Visited state information is not stored in the javascript heap (which is what this object contains information about). - James On Fri, Jun 4, 2010 at 12:06 PM, David Hyatt wrote: > I'm fairly certain I could construct an attack on :visited history privacy > using this object. > > dave > > On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > > On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: > >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> > > Why is the continuous integration/buildbot use-case of limited utility? Or > are you saying that Console.memory doesn't really support that use-case > well? I think we want to make it as easy as possible for complex apps (e.g. > email apps, mapping apps, etc.) to care about and monitor memory use. > > While I'm not convinced by the utility argument, I do buy the security > argument. How would you feel about leaving the code in, but disabling it by > default? Then it could be enabled by command-line or via a preference. > > That said, I'm OK with rolling back for now given that the code was > committed without this discussion actually coming to a conclusion. > > Ojan > ___ > 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] About fixing "old" layout bugs
For this particular bug (the one), even ref tests would be inadequate, since the reference renderings would have to change too. dave On Jun 4, 2010, at 2:17 PM, Dirk Pranke wrote: > One admittedly painful way to do this would be to dump two render > trees, an old format and a new format, and then build tooling to roll > between the versions. Most of the pain would probably be in modifying > the dump code to accept version flags and know whether to output old > or new as necessary. > > Of course, you can't really do this for pixel tests, so you're still > kind of stuck. > > ref tests might be a better answer in both situations. > > -- Dirk > > On Fri, Jun 4, 2010 at 10:36 AM, David Hyatt wrote: >> In fact the (really lousy) model I've employed in the past when this >> situation has arisen is that I hack the render tree dump to continue to dump >> the old rendering. The render tree dumping code is full of hacks as a >> result and is basically lying about many things at this point. >> It would be really nice to take the time to remove all of these hacks and >> just update every test, but we need a good solution for how to update many >> tests without breaking the tree. >> dave >> On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote: >> >> When there are only a couple tests that need new expectations, you can get >> away with committing your patch with the expectations for the platforms you >> have access to and then immediately grabbing the new expectations off the >> buildbots. >> >> There is currently no good way to address the cases where your patch causes >> many tests to need new results. There are ideas to make it better, but I >> don't think anyone is actively working on them. Specifically, the EWS bots >> could run the layout tests and give you access to the results. >> For now, with patches where you need to change many results and they're >> different on different platforms, you need to either get access to that >> platform, or get the help of someone who has access to it. >> Ojan >> >> On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang wrote: >>> >>> Hi, >>> I'm still wondering what the best practice is to deal with many updated >>> layout tests in a patch. It seems I must run the layout tests on all >>> effected platforms by myself to ensure a green build after committing the >>> patch, right? This is really difficult to me. Is there a easier way? >>> Thanks, >>> Xianzhu >>> >>> 2010/6/2 Xianzhu Wang Hi, I'm new to webkit development, and I'd like to hear opinions about the problems I met. Now I'm trying to fix some "old" layout bugs, for example: * white space preceding (https://bugs.webkit.org/show_bug.cgi?id=37261) * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) * line breaking around some punctuations (https://bugs.webkit.org/show_bug.cgi?id=37698) Some people have warned me about the difficulty of fixing these bugs, and now I have realized it. Fixing the bugs themselves is not very difficult, for example, only 2 functional lines change can fix the first bug. However, the change will break more than 4000 existing layout tests mostly because trailing spaces preceding s in current expectations of the tests (for example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests (for now on mac only), and the patch is about 6MB (Sorry I overlooked the "Bigfile" option when I submitted the patch, so I split it into 4 parts). My questions are: 1. The bugs violate the standards and cause some site compatibility issues. However, because the bugs are old, some web developers might treat them as features and depend on them, so fixing them might break some existing pages. Is there any existing policy about this problem? Are these bugs worth fixing? 2. What's the best practice to deal with a patche containing many updated layout test expectations? Is there a good way to rebaseline the effected tests on all platforms? Thanks, Xianzhu >>> >>> >>> ___ >>> 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] On adding 'console.memory' API (and about the whole 'console' object.)
On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafai wrote: > On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: > >> After talking it over with some folks here at Apple, I want to formally >> object to adding the Console.memory extension to the Console object and I >> think we should remove support for Console.profiles as soon as we can. They >> both provide information to users that are not generally useful (beyond the >> "continuous integration/buildbot" use-case which I think is of limited >> utility) and therefore should not be exposed to the web. >> > > Why is the continuous integration/buildbot use-case of limited utility? Or > are you saying that Console.memory doesn't really support that use-case > well? I think we want to make it as easy as possible for complex apps (e.g. > email apps, mapping apps, etc.) to care about and monitor memory use. > I am not saying that this API doesn't support the continuous integration/buildbot use-case, or support it well, I am saying that I don't think this is a use case we should be supporting in a web facing API. > While I'm not convinced by the utility argument, I do buy the security > argument. How would you feel about leaving the code in, but disabling it by > default? Then it could be enabled by command-line or via a preference. > > That said, I'm OK with rolling back for now given that the code was > committed without this discussion actually coming to a conclusion. > I would rather we didn't add more #ifdefs. Instead, this functionality should be available to native APIs (I believe it already is) -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About fixing "old" layout bugs
One admittedly painful way to do this would be to dump two render trees, an old format and a new format, and then build tooling to roll between the versions. Most of the pain would probably be in modifying the dump code to accept version flags and know whether to output old or new as necessary. Of course, you can't really do this for pixel tests, so you're still kind of stuck. ref tests might be a better answer in both situations. -- Dirk On Fri, Jun 4, 2010 at 10:36 AM, David Hyatt wrote: > In fact the (really lousy) model I've employed in the past when this > situation has arisen is that I hack the render tree dump to continue to dump > the old rendering. The render tree dumping code is full of hacks as a > result and is basically lying about many things at this point. > It would be really nice to take the time to remove all of these hacks and > just update every test, but we need a good solution for how to update many > tests without breaking the tree. > dave > On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote: > > When there are only a couple tests that need new expectations, you can get > away with committing your patch with the expectations for the platforms you > have access to and then immediately grabbing the new expectations off the > buildbots. > > There is currently no good way to address the cases where your patch causes > many tests to need new results. There are ideas to make it better, but I > don't think anyone is actively working on them. Specifically, the EWS bots > could run the layout tests and give you access to the results. > For now, with patches where you need to change many results and they're > different on different platforms, you need to either get access to that > platform, or get the help of someone who has access to it. > Ojan > > On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang wrote: >> >> Hi, >> I'm still wondering what the best practice is to deal with many updated >> layout tests in a patch. It seems I must run the layout tests on all >> effected platforms by myself to ensure a green build after committing the >> patch, right? This is really difficult to me. Is there a easier way? >> Thanks, >> Xianzhu >> >> 2010/6/2 Xianzhu Wang >>> >>> Hi, >>> I'm new to webkit development, and I'd like to hear opinions about the >>> problems I met. >>> Now I'm trying to fix some "old" layout bugs, for example: >>> * white space preceding >>> (https://bugs.webkit.org/show_bug.cgi?id=37261) >>> * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) >>> * line breaking around some punctuations >>> (https://bugs.webkit.org/show_bug.cgi?id=37698) >>> Some people have warned me about the difficulty of fixing these bugs, and >>> now I have realized it. Fixing the bugs themselves is not very difficult, >>> for example, only 2 functional lines change can fix the first bug. However, >>> the change will break more than 4000 existing layout tests mostly because >>> trailing spaces preceding s in current expectations of the tests (for >>> example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests >>> (for now on mac only), and the patch is about 6MB (Sorry I overlooked the >>> "Bigfile" option when I submitted the patch, so I split it into 4 parts). >>> My questions are: >>> 1. The bugs violate the standards and cause some site compatibility >>> issues. However, because the bugs are old, some web developers might treat >>> them as features and depend on them, so fixing them might break some >>> existing pages. Is there any existing policy about this problem? Are these >>> bugs worth fixing? >>> 2. What's the best practice to deal with a patche containing many updated >>> layout test expectations? Is there a good way to rebaseline the effected >>> tests on all platforms? >>> Thanks, >>> Xianzhu >> >> >> ___ >> 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] On adding 'console.memory' API (and about the whole 'console' object.)
I'm fairly certain I could construct an attack on :visited history privacy using this object. dave On Jun 4, 2010, at 2:02 PM, Ojan Vafai wrote: > On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: > After talking it over with some folks here at Apple, I want to formally > object to adding the Console.memory extension to the Console object and I > think we should remove support for Console.profiles as soon as we can. They > both provide information to users that are not generally useful (beyond the > "continuous integration/buildbot" use-case which I think is of limited > utility) and therefore should not be exposed to the web. > > Why is the continuous integration/buildbot use-case of limited utility? Or > are you saying that Console.memory doesn't really support that use-case well? > I think we want to make it as easy as possible for complex apps (e.g. email > apps, mapping apps, etc.) to care about and monitor memory use. > > While I'm not convinced by the utility argument, I do buy the security > argument. How would you feel about leaving the code in, but disabling it by > default? Then it could be enabled by command-line or via a preference. > > That said, I'm OK with rolling back for now given that the code was committed > without this discussion actually coming to a conclusion. > > Ojan > ___ > 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] On adding 'console.memory' API (and about the whole 'console' object.)
On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinig wrote: > After talking it over with some folks here at Apple, I want to formally > object to adding the Console.memory extension to the Console object and I > think we should remove support for Console.profiles as soon as we can. They > both provide information to users that are not generally useful (beyond the > "continuous integration/buildbot" use-case which I think is of limited > utility) and therefore should not be exposed to the web. > Why is the continuous integration/buildbot use-case of limited utility? Or are you saying that Console.memory doesn't really support that use-case well? I think we want to make it as easy as possible for complex apps (e.g. email apps, mapping apps, etc.) to care about and monitor memory use. While I'm not convinced by the utility argument, I do buy the security argument. How would you feel about leaving the code in, but disabling it by default? Then it could be enabled by command-line or via a preference. That said, I'm OK with rolling back for now given that the code was committed without this discussion actually coming to a conclusion. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the "continuous integration/buildbot" use-case which I think is of limited utility) and therefore should not be exposed to the web. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
On Fri, Jun 4, 2010 at 11:11 AM, Darin Adler wrote: > If the two enum types are identical except for their names, then this > doesn’t firewall the types at all. It doesn't firewall the concepts (but then, it's hard for an embedding layer to not transmit any concepts, as that's basically the point). It does firewall the actual #includes, and thus provides source independence for the embedder/a point where the WebKit side can be built as its own independent DLL (if we want to). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
If the two enum types are identical except for their names, then this doesn’t firewall the types at all. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
Was just hoping something easier might come along. I'll let the appropriate people know if I need any help thanx On Jun 4, 2010, at 11:04 AM, Peter Kasting wrote: > On Fri, Jun 4, 2010 at 10:54 AM, Chris Fleizach wrote: > For one, I would like to alphabetize that list. That will require hundreds of > changes, requiring me to make hundreds of blind changes in chromium code. > > When ARIA2 comes out, mayhaps there will be a dozen or two new additions. > > OK, but each of those seems like one change that touches multiple lines, not > dozens or hundreds of separate changes that will each individually cause a > separate problem. Alphabetize, see compile failure, alphabetize the other > list. > > I don't have a proposal for a better API. One of the primary purposes of > Chromium's WebKit API layer is to firewall WebKit types, so a replacement > design would have to be able to compile without referencing any WebKit > headers, which seems like it precludes something that automatically tracks > WebKit-side changes. Even Darin's mention of switch-based translations would > still require you to at least make changes for new and modified enum values > (though it would avoid problems due to simple reordering of the enums; but if > you're going to reorder once, that costs rather than saves effort). > > If it's any consolation, I'm sure any of us Chromium folk would be happy to > help make any Chromium-side changes necessary, if there's anything we can do > to help. And if I've missed a good replacement design, we're certainly open > to implementing different things in principle. > > PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
On Fri, Jun 4, 2010 at 10:54 AM, Chris Fleizach wrote: > For one, I would like to alphabetize that list. That will require hundreds > of changes, requiring me to make hundreds of blind changes in chromium code. > > When ARIA2 comes out, mayhaps there will be a dozen or two new additions. > OK, but each of those seems like one change that touches multiple lines, not dozens or hundreds of separate changes that will each individually cause a separate problem. Alphabetize, see compile failure, alphabetize the other list. I don't have a proposal for a better API. One of the primary purposes of Chromium's WebKit API layer is to firewall WebKit types, so a replacement design would have to be able to compile without referencing any WebKit headers, which seems like it precludes something that automatically tracks WebKit-side changes. Even Darin's mention of switch-based translations would still require you to at least make changes for new and modified enum values (though it would avoid problems due to simple reordering of the enums; but if you're going to reorder once, that costs rather than saves effort). If it's any consolation, I'm sure any of us Chromium folk would be happy to help make any Chromium-side changes necessary, if there's anything we can do to help. And if I've missed a good replacement design, we're certainly open to implementing different things in principle. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
For what it’s worth, this kind of pattern was quite common in the Mac OS X WebKit API, with public enums in the Objective-C API that exactly matched private enums inside WebCore and had to be kept in sync. Over the years, working towards the goal of making WebKit better cross-platform, we’ve tried to eliminate that, although I suspect there are some that remain. In some places that means we’re using switch statements to translate one enum to another, which of course has a bit of runtime cost. The Chromium use of this sort of pattern may be analogous. Or possibly it’s different, but just sounds similar. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
For one, I would like to alphabetize that list. That will require hundreds of changes, requiring me to make hundreds of blind changes in chromium code. It seems like rather bad form to duplicate core WebCore code used by all platforms, within one platform, and not a solution that is forward looking. When ARIA2 comes out, mayhaps there will be a dozen or two new additions. It just means every patch that goes in is going to fail to build and force someone to look through ported code so they can duplicate the work they just did. On Jun 4, 2010, at 10:45 AM, Peter Kasting wrote: > On Fri, Jun 4, 2010 at 10:14 AM, Chris Fleizach wrote: > Is there any way chromium can automate this so if it sees it is different, it > can re-generate to match the enums again > > Is it really that enormous of a problem? It doesn't seem like you're going > to be making hundreds of changes, and modifying two places, while not as > convenient as one, isn't anything we don't have to do elsewhere. > > PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?
On Fri, Jun 4, 2010 at 10:14 AM, Chris Fleizach wrote: > Is there any way chromium can automate this so if it sees it is different, > it can re-generate to match the enums again Is it really that enormous of a problem? It doesn't seem like you're going to be making hundreds of changes, and modifying two places, while not as convenient as one, isn't anything we don't have to do elsewhere. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] About fixing "old" layout bugs
In fact the (really lousy) model I've employed in the past when this situation has arisen is that I hack the render tree dump to continue to dump the old rendering. The render tree dumping code is full of hacks as a result and is basically lying about many things at this point. It would be really nice to take the time to remove all of these hacks and just update every test, but we need a good solution for how to update many tests without breaking the tree. dave On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote: > When there are only a couple tests that need new expectations, you can get > away with committing your patch with the expectations for the platforms you > have access to and then immediately grabbing the new expectations off the > buildbots. > > There is currently no good way to address the cases where your patch causes > many tests to need new results. There are ideas to make it better, but I > don't think anyone is actively working on them. Specifically, the EWS bots > could run the layout tests and give you access to the results. > > For now, with patches where you need to change many results and they're > different on different platforms, you need to either get access to that > platform, or get the help of someone who has access to it. > > Ojan > > > On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang wrote: > Hi, > > I'm still wondering what the best practice is to deal with many updated > layout tests in a patch. It seems I must run the layout tests on all effected > platforms by myself to ensure a green build after committing the patch, > right? This is really difficult to me. Is there a easier way? > > Thanks, > Xianzhu > > 2010/6/2 Xianzhu Wang > > Hi, > > I'm new to webkit development, and I'd like to hear opinions about the > problems I met. > > Now I'm trying to fix some "old" layout bugs, for example: > * white space preceding (https://bugs.webkit.org/show_bug.cgi?id=37261) > * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413) > * line breaking around some punctuations > (https://bugs.webkit.org/show_bug.cgi?id=37698) > > Some people have warned me about the difficulty of fixing these bugs, and now > I have realized it. Fixing the bugs themselves is not very difficult, for > example, only 2 functional lines change can fix the first bug. However, the > change will break more than 4000 existing layout tests mostly because > trailing spaces preceding s in current expectations of the tests (for > example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests > (for now on mac only), and the patch is about 6MB (Sorry I overlooked the > "Bigfile" option when I submitted the patch, so I split it into 4 parts). > > My questions are: > > 1. The bugs violate the standards and cause some site compatibility issues. > However, because the bugs are old, some web developers might treat them as > features and depend on them, so fixing them might break some existing pages. > Is there any existing policy about this problem? Are these bugs worth fixing? > > 2. What's the best practice to deal with a patche containing many updated > layout test expectations? Is there a good way to rebaseline the effected > tests on all platforms? > > Thanks, > Xianzhu > > > > ___ > 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] WebAccessibilityRole must match AccessiblityRole enums?
Is there any way chromium can automate this so if it sees it is different, it can re-generate to match the enums again On Jun 4, 2010, at 10:04 AM, Adam Barth wrote: > [+fishd] > > I believe this is a common pattern in the Chromium WebKit API. fishd > can speak to why this works the way it does in more detail. I believe > these enums exist to encapsulate WebCore types in the interface. > > Adam > > > On Fri, Jun 4, 2010 at 9:40 AM, Chris Fleizach wrote: >> Could someone explain why WebAccessibilityRole duplicates AccessibilityRole? >> >> This will make it very painful to change, re-order or add to >> AccessibilityRole as it becomes necessary in the future >> >> ie) see https://bugs.webkit.org/show_bug.cgi?id=40133 >> ___ >> 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] WebAccessibilityRole must match AccessiblityRole enums?
[+fishd] I believe this is a common pattern in the Chromium WebKit API. fishd can speak to why this works the way it does in more detail. I believe these enums exist to encapsulate WebCore types in the interface. Adam On Fri, Jun 4, 2010 at 9:40 AM, Chris Fleizach wrote: > Could someone explain why WebAccessibilityRole duplicates AccessibilityRole? > > This will make it very painful to change, re-order or add to > AccessibilityRole as it becomes necessary in the future > > ie) see https://bugs.webkit.org/show_bug.cgi?id=40133 > ___ > 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] WebAccessibilityRole must match AccessiblityRole enums?
Could someone explain why WebAccessibilityRole duplicates AccessibilityRole? This will make it very painful to change, re-order or add to AccessibilityRole as it becomes necessary in the future ie) see https://bugs.webkit.org/show_bug.cgi?id=40133 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Fri, Jun 4, 2010 at 1:54 AM, Mikhail Naganov wrote: > On Fri, Jun 4, 2010 at 05:57, Sam Weinig wrote: >> I should note, I don't think this is possible for JS objects, it certainly >> would not be possible for arbitrary WebCore/WebKit objects. I noticed the >> patch was re-landed, which surprises me since we are still discussing it, >> why was this? > > Well, I sent my last message 2 days ago, got no answer, and decided > that the discussion is finished by a timeout. I haven't seen any > serious concerns about this patch. Hum... That seems a bit agressive. Sometimes interacting with this project requires a bit more patience. My guess is that you've alienated Sam and whoever else was interested in discussing this topic further. :( Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Comments are inline. On Fri, Jun 4, 2010 at 05:57, Sam Weinig wrote: > I should note, I don't think this is possible for JS objects, it certainly > would not be possible for arbitrary WebCore/WebKit objects. I noticed the > patch was re-landed, which surprises me since we are still discussing it, > why was this? > -Sam > Well, I sent my last message 2 days ago, got no answer, and decided that the discussion is finished by a timeout. I haven't seen any serious concerns about this patch. > On Thu, Jun 3, 2010 at 5:02 PM, Timothy Hatcher wrote: >> >> Even if that wont prevent Sam's proposed information leak, I think this >> would be good to do. That way developers only see what they are affecting. >> Otherwise a developer might chase a red herring if they have Gmail or >> something open in the background and keep seeing spikes of memory are not >> caused by their page. >> Let's elaborate this a bit more. How I'm seeing this potential attack: another page (or an iframe) retrieves memory size and somehow deduces something based on memory consumption (current or over time) by an engine. If we restrict reported counts to include only page's (iframe's) memory it could only deduce things about itself, or about engine specifics, like, e.g. how many bytes does it take to hold a particular object. And even this data isn't exact now, because in JSC, the memory consumption is counted using the number of allocated blocks, so it's pretty coarse-grained. I agree that we (me, personally) should implement this filtering of memory consumption counter. I think, this should be possible for JS objects, if we involve the same mechanism that is used for enforcing single origin policy. >> On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: >> >> > Used memory count can be restricted to include only objects reachable >> > from the caller execution context. In this case, an app could only see >> > the amount of memory consumed by itself, not by the whole engine. >> >> — Timothy Hatcher >> >> ___ >> 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
