I have created a stripped-down test page at: http://44clarence.com/photos/index2.xxxx (The .xxxx extension is to ensure that the extension isn't affecting the behavior; it turns out the behavior is the same, regardless of whether I give it the extension *.html, *.xhtml or *.xxxx.) When using the version of Safari that shipped with OS X 10.5 (3.0.4 -- 5523.10) the Submit button on the above page does nothing when the page is served with the (correct) Content-type of: application/xhtml+xml However, the Submit button works properly when the page is served with the incorrect Content-type: text/html This is true regardless of whether the Content-type is set via the web server (by associating the content type with the extension, for example) or manually (by setting the header information using PHP, for example). Note that the page's extension does not affect the behavior, only the Content-type header (which is as it should be). I tried changing the extension to *.html, *.xhtml, and finally *.xxxx to ensure that it was in no way affecting the behavior. Note that this page is a valid XHTML 1.1 (Strict) document and it passes the W3C's validator. The page works correctly in Firefox (on both Windows and Macintosh), Opera, Opera Mini, Internet Explorer, and even the Palm Blazer web browser, among others. The above is a stripped-down version of the original page located at: http://44clarence.com/photos/
This bug has been confirmed with 4 separate Safari installations at 2 separate sites (3 at one site, 1 at the other), and this bug has been shown to occur with both OS X Leopard and OS X Tiger. Note that correctly submitting the password on the original page will set a browser cookie that allows you to bypass the login screen, so you need to ensure that all 44clarence.com cookies have been deleted prior to running a test on that page.
The page: http://44clarence.com/photos/index2.xxxx is currently being served with Content-type: application/xhtml+xml This has been verified using Firefox 3's Tools > Page Info command, which also shows it as having UTF-8 encoding and being rendered in Firefox's "Standards compliance mode".
I cannot reproduce this issue with Safari 3 on Tiger 10.4.11. > the Submit button on the above page does nothing What exactly does the behavior look like? Is the button highlighted when clicked? Does the URL change?
I have added a second copy of the same page with a different extension and a different Content-type: http://44clarence.com/photos/index2.yyyy This is served with the Content-type: text/html
(In reply to comment #3) > I cannot reproduce this issue with Safari 3 on Tiger 10.4.11. > > > the Submit button on the above page does nothing > > What exactly does the behavior look like? Is the button highlighted when > clicked? Does the URL change? The button "clicks" normally -- that is, it presses down like it should, but the form is not submitted and the browser goes nowhere.
Upon further investigation, it turns out that the machine(s) in question were running a piece of "password keychain" software from: http://www.1password.com/ which appears to be the culprit. When the Safari plugin for this software is disabled, the page works as expected regardless of the Content-type setting. A bug report will be filed with the offending company.
By the way, the offending version of 1Password is 2.5.4 (build 5707).