authorization do not work as an example try to login to icalx the panel for authorization do not open. in the log the following error apear 2007-05-05 20:41:07.900 WebKit[435] *** Assertion failure in -[BrowserApplication _commonBeginModalSessionForWindow:relativeToWindow:modalDelegate:didEndSelector:contextInfo:], AppKit.subproj/NSApplication.m:3057 2007-05-05 20:41:07.902 WebKit[435] Modal session requires modal window
I'm not able to reproduce this at all. Can you please provide more information about the steps required to reproduce this? Can you also verify that you do not have any Safari extensions (sometimes known as "plugins" or "haxies") installed, as they may be interfering.
(In reply to comment #1) > I'm not able to reproduce this at all. Can you please provide more information > about the steps required to reproduce this? Can you also verify that you do > not have any Safari extensions (sometimes known as "plugins" or "haxies") > installed, as they may be interfering. > In an account with admin privileges works ok, but in a standard even a new one just fresh created the authorization panel do not open when one try to login. (no haxies or plugins installed)
Without a valid username/password I have no way of knowing whether the authentication is working correctly or not. It seems quite probable that this is a server-side configuration issue as the few sites that I regularly use with HTTP authentication appear to be functioning correctly for me. We need more information to be able to reproduce this problem and determine where the issue lies.
I appologize if i didn´t explain myself correctly. the panel where the username and password should be introduced do not appear at all. So no need for a username/password pair if you get to the point where you can them you are not finding the bug. (In reply to comment #3) > Without a valid username/password I have no way of knowing whether the > authentication is working correctly or not. It seems quite probable that this > is a server-side configuration issue as the few sites that I regularly use with > HTTP authentication appear to be functioning correctly for me. We need more > information to be able to reproduce this problem and determine where the issue > lies. >
That being the case, I still cannot reproduce this. I'm using a relatively recent ToT build (21272) and visiting the above URL definitely gives me the authentication sheet.
is some kind of privilages permision problem. giving administrative privileges to an account make disappears the problem
I understand thats your claim - which is why I tried with a non-admin account. It worked just fine...
(In reply to comment #7) > I understand thats your claim - which is why I tried with a non-admin account. > It worked just fine... > I've encountered a page like this as well. When visiting: <http://senpef.oceanic.net.fj/> I'm presented with an error page and never see the authentication sheet. 2007-06-07 14:41:29 Rx <http://senpef.oceanic.net.fj/> 2007-06-07 14:41:29 Rx Status: 401 unauthorized 2007-06-07 14:41:29 Rx Headers: { Connection = close; "Content-Length" = 83; "Content-Type" = "text/html"; Date = "Thu, 07 Jun 2007 21:41:53 GMT"; Server = "Microsoft-IIS/6.0"; "Www-Authenticate" = Basic; "X-Powered-By" = "ASP.NET, PleskWin"; }
I can reproduce the problem on senpef.oceanic.net.fj, but not on icalx.com. Here are unmodified response headers: $ curl -I http://senpef.oceanic.net.fj/ HTTP/1.1 401 Unauthorized Content-Length: 83 Content-Type: text/html Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-Powered-By: PleskWin www-authenticate: Basic Date: Fri, 08 Jun 2007 11:00:54 GMT Connection: close
I got to resolve my problem. Seems that some of the nib file in the webCore framework inside the webkit bundle has gotten the wrong permision with a no-read for unprivilege account. I hope this could be of help
I think the problem on <http://senpef.oceanic.net.fj/> is related to or the same as: http://bugs.webkit.org/show_bug.cgi?id=5809 Someone may want to mark this bug as such since the original reporter has solved his problem.
*** This bug has been marked as a duplicate of 5809 ***