Last modified: 2010-05-16 16:30:20 UTC
Confirmed with Opera 8.54 on Mac OS X 10.5 Confirmed with a local copy of the login webpage that removing the jQuery imports from the HTML resolves the problem. With jQuery enabled, the following JS error is presented: Event thread: load Error: name: TypeError message: Statement on line 759: Could not convert undefined or null to object Backtrace: Line 759 of linked script http://en.wikipedia.org/skins-1.5/common/mwsuggest.js?227x if (element.addEventListener) else Line 777 of linked script http://en.wikipedia.org/skins-1.5/common/mwsuggest.js?227x os_hookEvent(document.getElementById(formname), "submit", function (event) { return os_eventOnsubmit(event); } ); Line 862 of linked script http://en.wikipedia.org/skins-1.5/common/mwsuggest.js?227x os_initHandlers(id, form, element); At unknown location [statement source code not available]
Trevor, can you confirm this? I can't even get Opera 8 or 8.5 to run without crashing on my Mac, and 9.6 doesn't seem to have any problems that I can clearly identify... not that we actually have jQuery enabled by default now. Possibly a side effect of the old bug w/ edit toolbar JS getting loaded when not needed?
With the recent fixes deployed, jQuery should not be loaded on the login page, which solves the issue at least temporarily.
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Opera_8 With the new acaifix active, we have received the first en.wp report of an Opera 8 user not able to edit, because on edit pages (wether you are part of beta or not) jquery is active, blocking something with the save button or something.
OK, I found the cause. Trough experimentation, it seems that in Opera 8, you cannot getElementById, a form (tested with both id= and name=). It seems it is not a DHTML element yet in that version. This causes 2 problems. In mwsuggest.js, in the function os_initHandlers(), there is the line os_hookEvent(document.getElementById(formname), "submit", function(event){ return os_eventOnsubmit(event); }); The second problem, and the one directly effecting the usability initiative is: addHandler(editForm, "submit", function () of edit.js The options are to either hide the bug by returning from os_hookevent() or addHandler() when the element is null (but this makes debugging more difficult), or by checking the document.getElementById result before attempting to add a handler. I think the latter in combination with a "opera 8 bug" comment, is the better solution. That should solve the error, though i'm not sure if functionality is restored after that. Versions of Opera 8 can be downloaded here: http://arc.opera.com/pub/opera/ You can test by saving a page (use the "with images" mode into a local directory.
For now, I've moved the "only use this for vector" logic out to the PHP level so we aren't sending jquery to people without any need for it. (r54607) - which doesn't actually solve the problem, but at least these people can edit using a skin other than vector.
It seems that edit.js now checks all return values of getElementById, so it should no longer be bothered by this. I have fixed mwsuggest in r66537
