Bug 77423 – Cannot login to Zyxel P-660HW-T1 v2 ADSL Router

• Component: Page Loading
• Status: UNCONFIRMED

[David Evans]

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.

[Alexey Proskuryakov]

Could you please find out which was the very first nightly builds where it stopped working? That would help investigation a lot.

[Alexey Proskuryakov]

<rdar://problem/10784076>

[David Evans]

(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

[David Evans]

(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.

[David Evans]

(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

[Alexey Proskuryakov]

> 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?

[Filip Pizlo]

(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.

[David Evans]

(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.

[Andy Estes]

(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?

[David Evans]

Created attachment 125156 [details]
Zyxel router login screen

[David Evans]

(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.

[Alexey Proskuryakov]

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.

[David Evans]

(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

[Alexey Proskuryakov]

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?

[Alexey Proskuryakov]

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.

[David Evans]

(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.

[David Evans]

(In reply to comment #14)
> 
> Me too! Are you using a network home directory, or maybe FileVault?

No, just a completely ordinary directory.