just to keep this thread up to date. I asked jduell if it is possible to change long to int64_t Am Freitag, 1. März 2013 04:11:40 UTC+1 schrieb bernha...@gmail.com: > Yep, you are right. I assumed nsIRequest would be the only file assigning > these values. > > > > What numbers should i choose? I need 2 flags and unsigned long only provides > 32 possibility which are already used (except 25) > > > > For me it would be ok to just fix the cookies issue :) But i guess there is a > reason why 25 is not used. > > > > -Bernhard > > Am Freitag, 1. März 2013 03:59:08 UTC+1 schrieb Boris Zbarsky: > > > On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote: > > > > > > > i have run hg pull and hg update on mozilla central and still have no > > > LOAD_DOCUMENT_URI. > > > > > > > > > > > > Are you looking in the right file? > > > > > > > > > > > > > The problem seems to be that this patch breaks the WHOLE Cookie handling > > > of firefox. > > > > > > > > > > > > Because your LOAD_NO_COOKIES has the same value as LOAD_DOCUMENT_URI. > > > > > > Which means it's getting set for every web page load. > > > > > > > > > > > > Oh, and your LOAD_NOAUTH_HEADER has the same value as > > > > > > LOAD_RETARGETED_DOCUMENT_URI which will lead to subtle bugs of its own, > > > > > > of course. > > > > > > > > > > > > You really can't introduce new flags to a bitfield that have the same > > > > > > values as existing flags. It just doesn't work well. ;) > > > > > > > > > > > > On a more serious note, I believe at this point all the flags except > > > > > > (1<<25) are in use on HTTP channel, between nsIRequest, nsIChannel, and > > > > > > nsICachingChannel.... > > > > > > > > > > > > -Boris
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
