You need to
before you can comment on or make changes to this bug.
After downloading Sunday's Nightly build i had no issues at home. but when coming to work where we have a proxy server, i get a "you are not connected to the internet" message when browsing.
Safari 3.1.1 and older nightly builds as well as other browsers and apps all function as expected.
I can confirm on Mac OS X 10.4.12. Regression testing puts the change between r32284 and r32341.
Error message on Mac OS X 10.4.12 is the following, regardless of whether the server is being accessed through the proxy:
Safari can’t connect to the server.
Safari can’t open the page “http://nightly.webkit.org/start/trunk/32341” because it could not connect to the server “nightly.webkit.org”.
Are you using a PAC file to configure proxy support?
we have both PAC file and a traditional HTTP proxy and it looks like it is only happening when i use a pac file.
i personally have the pac file saved on my local machine, but most users have a URL pointing to it.
Would you be able to upload the PAC file here for testing (if it doesn't contain any sensitive information)?
There were some recent changes that could easily affect PAC file handling, but those were all before r32284. Could you please double-check if that revision works for you? Also, could you try manually configuring proxy settings to make sure that it is PAC file handling that is broken?
I do see some weirdness with nightly builds and PAC files, and will try to fix what I see - but it would still help to get answers to the above questions.
i'll be able to look into this more next week from the office. sorry for the delay
After some testing I found WebKit 31916 the last working version, 31981 contains the bug. I scanned all ChangeSets between 31917 and 31981, but found nothing obvious.
I don't get the same error message as Kenny, however. In my case Gmail doesn't load: The "Loading..." doesn't go away and progress stops. This doesn't happen all the time. When it works WebKit is much slower than normal, though.
@Alexey: I will send my PAC file by direct email, I don't want it to be publicly available.
Created an attachment (id=20814) [details]
Fix - work in progress
This should fix the problem, but causes a performance regression on SunSpider, so it needs more work.
Created an attachment (id=20866) [details]
** TOTAL **: 3419.0ms +/- 0.1% 3419.7ms +/- 0.2%
3d: *1.005x as slow*
morph: *1.003x as slow*
raytrace: *1.013x as slow*
access: 1.006x as fast
fannkuch: 1.009x as fast
nbody: 1.006x as fast
bitops: *1.005x as slow*
3bit-bits-in-byte: *1.026x as slow*
bitwise-and: *1.004x as slow*
aes: *1.008x as slow*
spectral-norm: 1.004x as fast
regexp: 1.004x as fast
dna: 1.004x as fast
unpack-code: *1.009x as slow*
(From update of attachment 20866 [details])
192 ExecState(JSGlobalObject*, JSObject* thisObject, JSObject* globalThisValue, FunctionBodyNode*, ExecState* callingExecState, FunctionImp*, const List& args) __attribute__ ((__always_inline__));
This needs to use the ALWAYS_INLINE macro so it will compile in non-GCC compilers.
66 extern HashTable arrayTable;
67 extern HashTable dateTable;
68 extern HashTable mathTable;
69 extern HashTable numberTable;
70 extern HashTable RegExpImpTable;
71 extern HashTable RegExpObjectImpTable;
72 extern HashTable stringTable;
Since these are global identifiers with external linkage, I would prefer that they had more-specific suffixes on the names -- "Table" doesn't say it all to me. But I guess these names aren't new.
6465 class SyntaxErrorPrototype;
66 struct ThreadClassInfoHashTables;
6567 class TypeError;
We normally put the struct declarations in a separate paragraph below the class ones.
72 if (classPropHashTableGetterFunction)
73 return classPropHashTableGetterFunction(exec);
75 return staticPropHashTable;
We normally omit else before return.
Is this portable to all platforms where we use pthreads?
review- because of the ALWAYS_INLINE issue above.
Created an attachment (id=20869) [details]
(In reply to comment #10)
> This needs to use the ALWAYS_INLINE macro so it will compile in non-GCC
Oops - this wasn't even supposed to be in the patch, was just an experiment.
> We normally put the struct declarations in a separate paragraph below the class
> We normally omit else before return.
> 134 usleep(1000);
This file is currently only used on Mac.
(From update of attachment 20869 [details])
Committed revision 32652.
I tested nightly build #32652 with the proxy PAC file that let previous WebKit fail: It now works.
Thanks for your work, Alexey!