Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Hi, The mirror is finally ready again: https://github.com/WebKit/webkit It now follows the same hashes of git.webkit.org. People who have forked this repository on github before will now have to rebase their branches. I was hold back a bit because Github wasn't allowing me to push more than 2GB. I contacted them but before I could get answer I decide to 'split' the push. First I git reset --hard the repository back to a commit from 2008, pushed this, then reset --hard to 2009 and pushed this, and so on. In the middle of the process the folks from github increased our push limit to 20GB and David (barrbrain) was kind enough to push one last sync, getting us back to 2012. After that I kept the syncing manullay for a few hours but now the repository is being updated automatically every 5 minutes to stay in sync with git.webkit.org . I will now coordinate with William so we can get Apple pushing to the mirror at the same time they push to git.webkit.org . Thanks everyone that got involved for the help! Cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org
[webkit-dev] request of canconfirm-bit
Hello everyone This is Zheng and nice to meet you. I want to confirm some issue(https://bugs.webkit.org/show_bug.cgi?id=78957) and try to create patch for it. However, it seems I need canconfirm-bit based on http://www.webkit.org/quality/bugzilla.html So, could someone give me the right to confirm and fix it. BR, Zheng ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] request of canconfirm-bit
We more or less ignore the is confirmed bit in bugs.webkit.org. Adam On Wed, Jan 16, 2013 at 6:35 AM, 徐征 xz91...@yahoo.co.jp wrote: Hello everyone This is Zheng and nice to meet you. I want to confirm some issue(https://bugs.webkit.org/show_bug.cgi?id=78957) and try to create patch for it. However, it seems I need canconfirm-bit based on http://www.webkit.org/quality/bugzilla.html So, could someone give me the right to confirm and fix it. BR, Zheng ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] request of canconfirm-bit
On Jan 16, 2013, at 9:19 AM, Adam Barth aba...@webkit.org wrote: We more or less ignore the is confirmed bit in bugs.webkit.org. I believe it’s possible to rename UNCONFIRMED to NEW and delete NEW so we can get rid of this distinction that we don’t make use of. Might be worth doing at some point to reduce confusion. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
If you were using GitHub to contribute to WebKit previously, you might want to delete your fork of https://github.com/WebKit/webkit and re-fork https://github.com/WebKit/webkit. It's also possible to push a force update to your repository that re-writes the hashes, but I found that re-forking was easier. Adam On Wed, Jan 16, 2013 at 4:55 AM, Jesus Sanchez-Palencia je...@webkit.org wrote: Hi, The mirror is finally ready again: https://github.com/WebKit/webkit It now follows the same hashes of git.webkit.org. People who have forked this repository on github before will now have to rebase their branches. I was hold back a bit because Github wasn't allowing me to push more than 2GB. I contacted them but before I could get answer I decide to 'split' the push. First I git reset --hard the repository back to a commit from 2008, pushed this, then reset --hard to 2009 and pushed this, and so on. In the middle of the process the folks from github increased our push limit to 20GB and David (barrbrain) was kind enough to push one last sync, getting us back to 2012. After that I kept the syncing manullay for a few hours but now the repository is being updated automatically every 5 minutes to stay in sync with git.webkit.org . I will now coordinate with William so we can get Apple pushing to the mirror at the same time they push to git.webkit.org . Thanks everyone that got involved for the help! Cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org http://lists.webkit.org/__mailman/listinfo/webkit-dev http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Do we know if there is a way to re-write our existing forks w/o pulling the whole repo down, just to push it back up again? :) On Wed, Jan 16, 2013 at 11:51 AM, Adam Barth aba...@webkit.org wrote: If you were using GitHub to contribute to WebKit previously, you might want to delete your fork of https://github.com/WebKit/webkit and re-fork https://github.com/WebKit/webkit. It's also possible to push a force update to your repository that re-writes the hashes, but I found that re-forking was easier. Adam On Wed, Jan 16, 2013 at 4:55 AM, Jesus Sanchez-Palencia je...@webkit.org wrote: Hi, The mirror is finally ready again: https://github.com/WebKit/webkit It now follows the same hashes of git.webkit.org. People who have forked this repository on github before will now have to rebase their branches. I was hold back a bit because Github wasn't allowing me to push more than 2GB. I contacted them but before I could get answer I decide to 'split' the push. First I git reset --hard the repository back to a commit from 2008, pushed this, then reset --hard to 2009 and pushed this, and so on. In the middle of the process the folks from github increased our push limit to 20GB and David (barrbrain) was kind enough to push one last sync, getting us back to 2012. After that I kept the syncing manullay for a few hours but now the repository is being updated automatically every 5 minutes to stay in sync with git.webkit.org . I will now coordinate with William so we can get Apple pushing to the mirror at the same time they push to git.webkit.org . Thanks everyone that got involved for the help! Cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list
Re: [webkit-dev] request of canconfirm-bit
Thank you Adam and Darin So, how can I get assign for this issue(and make the status to ASSIGNED)? Should I get connect with reporter? Now I am reading http://www.webkit.org/quality/lifecycle.html. Zheng (2013/01/17 2:25), Darin Adler wrote: On Jan 16, 2013, at 9:19 AM, Adam Barth aba...@webkit.org wrote: We more or less ignore the is confirmed bit in bugs.webkit.org. I believe it’s possible to rename UNCONFIRMED to NEW and delete NEW so we can get rid of this distinction that we don’t make use of. Might be worth doing at some point to reduce confusion. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to remove list-item special counter
On Wed, Aug 15, 2012 at 3:50 PM, Darin Adler da...@apple.com wrote:
On Aug 15, 2012, at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:
WebKit is the only browser that implements the magic counter named
list-item and we have no tests for it.
Seems like we really ought to add some tests for it.
It's not useful since we don't support the ::marker pseudo element
Maybe it can’t be used for its best and most obvious uses without
::marker, but it still work and can be used for some things. Here’s an
example of it doing some good:
style #list-count:before { counter-increment: list-item -1; content:
counter(list-item); } /style
ol
liA/li
liB/li
liC/li
/ol
The list above has span id=list-count/span items in it.
I’m still OK with removing it if there is an argument that the current
implementation does more harm than good.
I've scoured the web and can't find any reference to anyone using it,
mention of it's usage on any pages and no other browser supports it. In
terms of harm, it adds implementation complexity, especially when I want to
rewrite counters to be much simpler and faster.
I'd like to go ahead with the removal and then we can bring this back if
developers show interest. Does that sound reasonable?
- E
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal to remove list-item special counter
On Jan 16, 2013, at 5:46 PM, Elliott Sprehn espr...@chromium.org wrote: I've scoured the web and can't find any reference to anyone using it, mention of it's usage on any pages and no other browser supports it. How much more common is use of the rest of the counters specification? I understand that counters is still a leading-edge feature that isn’t likely to be used much on the real web yet. The list-item counter is used in the very first example in the CSS Lists and Counters Module http://www.w3.org/TR/css3-lists/. I don’t understand why you are so eager to throw it under the bus. In terms of harm, it adds implementation complexity, especially when I want to rewrite counters to be much simpler and faster. I'd like to go ahead with the removal and then we can bring this back if developers show interest. Does that sound reasonable? If you really want to remove it, and all the other browser vendors agree, maybe you can get it removed from the CSS working draft. If someone showed up today saying they wanted to add it, I would support that, so I’m still not convinced that removing it is the way to go. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] request of canconfirm-bit
On Jan 16, 2013, at 2:54 PM, 徐征 xz91...@yahoo.co.jp wrote: So, how can I get assign for this issue(and make the status to ASSIGNED)? You don’t need to. You can add comments and post a patch without having the bug formally assigned to you. In fact, we don’t normally pay all that much attention to the Assigned To field. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Need information regarding CSS3 extension
Hi , I want to write CSS3 extension, I don’t have any idea about it. I saw the code related to css in webkit but I am getting difficulties to map it. I. want to develop own tag like webkit-animation. Please let me know if anyone having any idea about CSS extension. Regards, MK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)
Hi Adam, You raise a number of interesting points which I'll try to address. On Jan 12, 2013, at 1:14 AM, Adam Barth aba...@webkit.org wrote: On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak m...@apple.com wrote: Do you think thread in the UI process vs. completely separate process is a topic worth discussing? It seems like the WebCore layer is unaffected by the difference, and in fact the impact of Chromium's choice is not even visible in the WebKit repository afaict. I don't know. As I wrote above, I haven't really thought through the consequences of that design choice. My point was just that the design wasn't discussed with the community at all. The NetworkProcess and its nature as a process have been mentioned before. At the time, no one expressed an opinion about the matter or pressed for an alternative, and it seems you have not (yet) done so either. If you have an interest in discussing it yourself, I at least would be happy to discuss it. If, for example, you would like to ask questions about it, advocate for a different design, argue that it's important for WK2 and Cr architectures to be consistent in this regard, present the Chromium team's reasons for choosing a thread, or anything else, then I would gladly engage in such discussion. Indeed, if anyone has a substantive point to make, I'll concede the foul of insufficient prior discussion. If no one does, then it doesn't seem very valuable to debate the meta-point. (One reason for our particular choice, FYI, is so that we can give the NetworkProcess a tighter sandbox profile than the Safari UI process). I'm surprised that the Mac OS X sandboxing mechanisms are sophisticated enough to provide a meaningful sandbox for the NetworkProcess. That's certainly not possible on other platforms (e.g., Windows). The reference monitor we use in Chromium for network requests contains a great deal of web-specific details that are necessary to prevent, for example, an attacker from stealing confidential information (such as tax returns) stored in the user's file system. I take your word for it that it's not possible on Windows. I believe that the NetworkProcess can feasibly be denied the following privileges via Mac OS X sandboxing mechanisms, whereas none of these can feasibly be denied to the UI process: - Access to the window server - Access to the pasteboard server - Access to arbitrary local files in the filesystem I'm going to guess you are the most skeptical about whether the third can be done in a meaningful way. If you would like to get deep into the details of how it might be done, then I'd sincerely love to have your expert review, but it might be something that we should discuss outside this thread. However, to give you a quick overview: Mac OS X sandboxing mechanisms allow fine-grained control over the file access for a process. The sandbox profile's rules can allow or deny access to any section of the filesystem. There is also a way to dynamically grant temporary access to a given file or portion of the filesystem from a more privileged process. Deny rules can also take precedence over extensions. Thus, at minimum, it is straightforward to achieve the following: (1) When the user has not explicitly opened any local files, the NetworkProcess can only access its assigned whitelist of files (including such things as cache and cookies directories, for instance). (2) For the duration of the user having an explicitly chosen local document open, the NetworkProcess can be temporarily granted access to the whole filesystem excepting sensitive blacklisted areas. (2) is obviously suboptimal, since social engineering attacks could be used to trick a user into opening a local file, but it does prevent drive-by attacks. But it's possible to do better with more work. Let me throw out two rough strawman designs. Let's presume for both of these that local files are opened in separate WebProcesses from any remote webpages. There are at least two approaches to avoiding giving the NetworkProcess the run of the filesystem even temporarily. One is to grant the extension the local file WebProcesses, and have them load files directly rather than via proxy. Another is to have a FileAccessProcess or the like which only handles file: URLs but otherwise works like the NetworkProcess, and only WebProcesses serving a local file document would be given a handle to it. There might be other even more clever ways but I hope this suffices for an existence proof. Again, we could dig more into the details, but I think that would merit a separate discussion (perhaps off of webkit-dev). For these reasons, I am reasonably confident that a separate process for networking can be made to have better security properties on Mac OS X (and platforms with similarly sophisticated sandboxing mechanisms) than a thread inside the UI process. And these better properties are intrinsically tied to being a
