jQuery is breaking mwsuggest preventing users of Opera 8 to log into en.wp
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	TheDJ
	Jul 8 2009, 1:29 PM

Description

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]

Version: unspecified
Severity: critical
URL: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Login_problem

Details

Reference: bz19586

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:41 PM

• bzimport added a project: MediaWiki-User-login-and-signup.

• bzimport set Reference to bz19586.

TheDJ created this task.Jul 8 2009, 1:29 PM

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

jQuery is breaking mwsuggest preventing users of Opera 8 to log into en.wpClosed, ResolvedPublicActions

Description

Details

Event Timeline

jQuery is breaking mwsuggest preventing users of Opera 8 to log into en.wp
Closed, ResolvedPublic
Actions