Hi,
I think the Windows tester bot is bigger problem if you would like to
unskip/rebase
tests, because it exits early long long time ago because of too many failing
tests.
http://build.webkit.org/builders/Windows%207%20Release%20%28Tests%29/builds/24196
fast/repaint/moving-shadow-on-path.html
Referring to the class (?):
FirstPartyForCookies
After a look up at the code, I can found it recurring in:
src/WebURLRequest.cpp
src/WebDocument.cpp
loader/FrameLoader.cpp
Any code reference (link) to the main code implementation would be useful.
Giorgio
trac.webkit.org is your friend here.
For example, searching for 3rd party cookie (per the title of your
mail), finds:
http://trac.webkit.org/search?q=3rd+party+cookie
There are also various code-search tools on the web, including
Chromium's (which will search the full source of WebKit):
On Tue, May 29, 2012 at 10:05 AM, Eric Seidel e...@webkit.org wrote:
There are also various code-search tools on the web, including
Chromium's (which will search the full source of WebKit):
http://code.google.com/p/chromium/source/search
To search WebKit specifically, you can further add
Thank you for replying me and for your suggestions.
Through trac, I a looking up for the class (not sure if technically speaking is
a class):
FirstPartyForCookies
It compares in many files: how to understand which one is the main
implementation?
Giorgio
On Tue, May 29, 2012 at 10:55 AM, Giorgio Mazzucchelli
giorgio@gmail.com wrote:
Thank you for replying me and for your suggestions.
Through trac, I a looking up for the class (not sure if technically speaking
is a class):
FirstPartyForCookies
It compares in many files: how to
The windows test bot currently has a problem that we are trying to diagnose.
For some reason, it is putting layout test results in
build/OpenSource/OpenSource. We took the test bot offline to diagnose which
step this was happening, however we haven't found it yet. We will continue to
Is the mechanism of handling 3rd part cookies by WebKit documented somewhere?
Not directly referring to source code.
Giorgio
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
This list is not the appropriate forum for your questions.
Adam
On May 29, 2012 11:39 AM, Giorgio Mazzucchelli giorgio@gmail.com
wrote:
Is the mechanism of handling 3rd part cookies by WebKit documented
somewhere? Not directly referring to source code.
Giorgio
Hi Webkit-dev,
I just wanted to let you know that I'm about to add initial support (
https://bugs.webkit.org/show_bug.cgi?id=87403) for two new minor CSS media
query features:
http://dev.w3.org/csswg/css4-mediaqueries/#pointer
http://dev.w3.org/csswg/css4-mediaqueries/#hover
Ports can opt into
There's a lot of confusion in the code base about how page and device
scaling works. Different ports are using Page::deviceScaleFactor for
incompatible purposes. On Mac, Page::deviceScaleFactor represents the
actual scaling factor of the physical device. It can change over time
because a given
On Tue, May 29, 2012 at 7:03 PM, Fady Samuel fsam...@chromium.org wrote:
This sounds good to me, but is there any reason why we can't support
physical device changes (switching monitors) and support target-densitydpi?
This would be highly desirable for us.
We can support that. We just need to
On Tue, May 29, 2012 at 9:54 PM, Adam Barth aba...@webkit.org wrote:
There's a lot of confusion in the code base about how page and device
scaling works. Different ports are using Page::deviceScaleFactor for
incompatible purposes. On Mac, Page::deviceScaleFactor represents the
actual
How will these changes affect window.devicePixelRatio and the associated media
queries? Will they still key off of Page::deviceScaleFactor?
Konrad
Sent from my BlackBerry on the Rogers Wireless Network
- Original Message -
From: Adam Barth [mailto:aba...@webkit.org]
Sent: Tuesday, May
Thanks for looking into this, I like this naming scheme and Chrome for
Android would be willing to switch to it.
Another major semantic question is how deviceScaleFactor relates to the
FrameView viewport size. Currently on Chrome for Android and Qt ports, the
viewport is just the physical pixel
On Tue, May 29, 2012 at 7:23 PM, Konrad Piascik kpias...@rim.com wrote:
How will these changes affect window.devicePixelRatio and the associated
media queries? Will they still key off of Page::deviceScaleFactor?
There's been a bunch of discussion about that topic in
Can you explain why the target-densitydpi feature even exists? It seems
ill-conceived to me, and the most straightforward fix would be to remove it. I
have not heard anyone explain the use case for it. (I'm also not clear on the
details of what it actually does, and neither the name nor the
17 matches
Mail list logo
