You can't store much data in cookies and thus you're only shooting yourself
in the foot with a bb gun. 5mb means you're shooting yourself in the foot
with a real gun. And if you're allowing over 5mb, it's a bazooka.
Anyway, I've written extensively about this many times on many different
lists.
On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow wrote:
> You can't store much data in cookies and thus you're only shooting yourself
> in the foot with a bb gun. 5mb means you're shooting yourself in the foot
> with a real gun. And if you're allowing over 5mb, it's a bazooka.
...and for this rea
On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
> clients:
>
> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const
> Node*), EditingBoundaryCrossingRule rule)
>
> It takes a boolean function that take
On 10/6/10 8:00 PM, Darin Adler wrote:
For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s
now showing up in Apple’s Software Update for all Xcode users, I believe.
I opened https://bugs.webkit.org/show_bug.cgi?id=62011 to get the web
site updated to indicate >= 3.2.
On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
> On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
>
>> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
>> clients:
>>
>> Node* enclosingNodeOfType(const Position& p, bool (*nodeIsOfType)(const
>> Node*), EditingBoundaryCro
Either (1) or (2) is fine. Please pick one and do it. The status quo
is very annoying.
Adam
On Tue, May 31, 2011 at 6:58 AM, Ademar Reis wrote:
> On Thu, May 26, 2011 at 7:54 PM, Eric Seidel wrote:
>> I get a lot of these:
>> Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab
On Jun 3, 2011, at 9:28 AM, Maciej Stachowiak wrote:
> On Jun 3, 2011, at 7:50 AM, Darin Adler wrote:
>
>> On Jun 2, 2011, at 1:32 AM, Ryosuke Niwa wrote:
>>
>>> All functions passed to enclosingNodeOfType in htmlediting.cpp are such
>>> clients:
>>>
>>> Node* enclosingNodeOfType(const Positio
On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler wrote:
> From a const Node* you can get:
>
>- a non-const pointer to a parent, sibling, or child
>- a non-const pointer to the document
>- a non-const pointer to the renderer
>- a non-const pointer to the style
>- a non-const pointer
On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote:
> From the perspective of Node itself, I'm not sure why this would be a "big
> task". There shouldn't be any const accessors that return non-const pointers.
> Simply removing the "const" qualifier on all the above accessors would make
> things co
9 matches
Mail list logo