I have a Zyxel P-660HW-T1 v2 ADSL router. I cannot login to it any more. After I enter the password (1234) the login screen is displayed again. Login works using normal Safari, Chrome 17.0, and Firefox 9.0.1 Safari Webkit Version 5.1.2 (6534.52.7, r106324) does not work (Nightly build). It has been failing for the last few weeks. I suspect it is something to do with popups, but I'm not really sure. I've guessed the component is JavaScript Core.
Could you please find out which was the very first nightly builds where it stopped working? That would help investigation a lot.
<rdar://problem/10784076>
(In reply to comment #2) > <rdar://problem/10784076> (In reply to comment #1) > Could you please find out which was the very first nightly builds where it stopped working? That would help investigation a lot. I retrieved the old Webkits from the trash and tested each one of them. Needless to say, they all worked! Even the ones that were only a few days old. The current Webkit is still failing. I don't understand this at all. I will wait until another Webkit turns up and see if the current Webkit is still failing when I fetch it from the Trash. I don't think the router is setting any cookies or any other state in the browser. Just to make sure, I cleared all cookies. I will have to be more thorough in the testing procedure and I will repeat the tests. The testing procedure I will use in future will be this: 1. If logged into the router, logout using the control in the top right-hand corner of the screen. 2. cmd-Q from all active Webkits and Safaris (quit) 3. Start a candidate Webkit and see if I can login
(In reply to comment #3) > (In reply to comment #2) > > <rdar://problem/10784076> > A new Webkit was available so I tried it and it failed. I retrieved the previous version to my ~/webkit-bisect directory and it now worked. I moved the previous version to my /Users/davidevans/Applications directory, which is where I normally run WebKit from, and it failed. It seems that WebKit will only fail if it is named WebKit.app AND it is in my /Users/davidevans/Applications directory. Anything else and it works. I tried all the revisions that I retrieved from the trash and here are the results: r101445 pass r101726 pass r102255 pass r102809 pass r103070 pass r103145 pass r103186 pass r103236 pass r103654 fail r104047 fail r104140 fail r104346 fail r104486 fail r105030 fail r106102 fail r106324 fail I will now download the nightly builds between r103236 and r103654 to narrow it down a bit more. Stay tuned.
(In reply to comment #4) > > I will now download the nightly builds between r103236 and r103654 to narrow it down a bit more. Stay tuned. I've now bisected the nightly builds from the archive. r103386 passes and r103402 fails
> It seems that WebKit will only fail if it is named WebKit.app AND it is in my /Users/davidevans/Applications directory. Anything else and it works. This is very strange. How WebKit.app works is that it simply launches your usual Safari.app using a newer WebKit framework from inside WebKit.app bundle. I haven't seen any bugs where location of WebKit.app was changing the behavior. > I've now bisected the nightly builds from the archive. r103386 passes and r103402 fails Thank you very much! The mystery above notwithstanding, this is a very short range with few substantial changes. The only one that could theoretically affect behavior are JavaScriptCore changes in <http://trac.webkit.org/changeset/103390> and <http://trac.webkit.org/changeset/103392>. Filip, could you take a look to see if anything stand out to you?
(In reply to comment #6) > > It seems that WebKit will only fail if it is named WebKit.app AND it is in my /Users/davidevans/Applications directory. Anything else and it works. > > This is very strange. > > How WebKit.app works is that it simply launches your usual Safari.app using a newer WebKit framework from inside WebKit.app bundle. I haven't seen any bugs where location of WebKit.app was changing the behavior. > > > I've now bisected the nightly builds from the archive. r103386 passes and r103402 fails > > Thank you very much! The mystery above notwithstanding, this is a very short range with few substantial changes. > > The only one that could theoretically affect behavior are JavaScriptCore changes in <http://trac.webkit.org/changeset/103390> and <http://trac.webkit.org/changeset/103392>. Filip, could you take a look to see if anything stand out to you? http://trac.webkit.org/changeset/103392 only affects 32-bit, and it looks like David is running 64-bit. http://trac.webkit.org/changeset/103390 is a mechanical refactoring and is extremely low-risk. I don't think that those changes are to blame.
(In reply to comment #7) I've tried running WebKit from /Applications and it worked. I've also tried it in another user's ~/Applications directory and that worked as well. So I wonder what is special about my ~/Applications directory. I'm willing to bisect it down a bit more if someone can tall me how to generate a disk image. I suspect running Webkit from the script will probably work. I've built Webkit in the past but only ran it from the script. It may be that there is something amiss with the Zyxel login page so I will attach it to this bug.
(In reply to comment #7) > (In reply to comment #6) > http://trac.webkit.org/changeset/103392 only affects 32-bit, and it looks like David is running 64-bit. I don't think it's safe to assume he's running a 64-bit machine. 10.6 supported 32-bit Intel processors. David, can you tell us what model of Mac you're using?
Created attachment 125156 [details] Zyxel router login screen
(In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > http://trac.webkit.org/changeset/103392 only affects 32-bit, and it looks like David is running 64-bit. > > I don't think it's safe to assume he's running a 64-bit machine. 10.6 supported 32-bit Intel processors. David, can you tell us what model of Mac you're using? Model Name: iMac Model Identifier: iMac7,1 Processor Name: Intel Core 2 Duo Processor Speed: 2.4 GHz Number Of Processors: 1 Total Number Of Cores: 2 It is 64 bit.
Could you re-download disk images of r103386 and r103402 from http://nightly.webkit.org, and run WebKit.app directly from these? Maybe WebKit's auto-update is confusing the matters with read-write bundles.
(In reply to comment #12) > Could you re-download disk images of r103386 and r103402 from http://nightly.webkit.org, and run WebKit.app directly from these? Maybe WebKit's auto-update is confusing the matters with read-write bundles. r103386 works both from the dmg and if copied to ~/Applications r103402 works from the dmg and fails if copied to ~/Applications
That's quite a mystery. > So I wonder what is special about my ~/Applications directory. Me too! Are you using a network home directory, or maybe FileVault?
Oh. Do you see any WebProcess crash logs in Console.app that would correspond to the time of attempted logins? A crash in WebProcess may look like a page reload, but a crash log will be saved behind the scenes.
(In reply to comment #15) > Oh. Do you see any WebProcess crash logs in Console.app that would correspond to the time of attempted logins? No, nothing except a few messages about obsolete X509 anchors and possible memory leaks, nothing corresponding to the time of login.
(In reply to comment #14) > > Me too! Are you using a network home directory, or maybe FileVault? No, just a completely ordinary directory.