242429 - autumnwindsagility.com - mouse cannot set form field focus; keyboard still can

Status: RESOLVED INCOMPLETE

(Tech Evangelism Graveyard :: English US, defect)

Description

[andrew]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

PLEASE PUT "TEST" in the comment field if you're filling out the form in the URL
above!

When filling in the form on the URL above, the mouse cannot be used to switch
focus from one text element to the next. Focus seems to be continually reset to
the URL navigation bar for some reason. Using TAB to switch between text
elements still works, however.

This may be an interaction with the form auto-filler; try submitting more than
one request.

Reproducible: Always
Steps to Reproduce:
1. Surf to http://www.autumnwindsagility.com/html/mailing_list.html
2. Click on the "Your email address" text field, and fill it in (please use an
obvious 'test' address!)
3. Try using the keyboard to click on the 'your real name' text area
4. Your mouse click is ignored. (you can repeat this) If you double-click (or
click rapidly enough) sometimes (rarely) the filed is auto-filled for you with a
past entry.
5. Use tab to switch to the 'real name' input field; this works.

Actual Results:  
Repeatable, even if you clear the cache, remove managed (stored) form
information, etc.

Expected Results:  
Acted like any normal form.

This behavior only seems to occur when the form's onsubmit handler is
dynamically set on page load.

NetObjects 7.5 was used to build the site and scripting actions; the generated
scripts seem to be fine and valid for a wide range of old and new broswers.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not a bug in form manager.

The site is cancelling mousedown events.  Since form fields are focused on
mousedown, cancelling those events should in fact make it impossible to focus
form fields by mouse.  Not a Mozilla bug but a problem with the site.

Comment 2

[andrew]

Hmm... so I'm tracing the F_nn_mouseDown function in "assets/script.js"... and I
can't see why we are returning "false". Is that where you see the problem?

If I can track this down a little more, I can file the right bug report with the
right people.

Thanks,
-Andrew.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Where's routeEvent() defined?

Comment 4

[andrew]

The window, document, and layer objects all define the routeEvent method as an
aid in event handling.

I'm interested in how you know the mousedown event is being cancelled. My
Venkman skills are rather poor, and I just can't seem to step through and trace
everything at runtime. (I'm just "visually tracing" things.)

Sigh.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yes, but _where_ are they defining it?  I don't see it in the scripts....

I can tell it's being cancelled because inputs don't focus and selection doesn't
work -- the only thing those have in common is that they trigger off mousedown.

Comment 6

[andrew]

Sorry - perhaps I wasn't clear. Netobjects (and the site) don't define the
"routeEvent" method; it is a "core" pre-defined method common to all default
Window, Layer, and Document objects in javascript. Take a look at
<http://developer.netscape.com/docs/technote/javascript/eventhandler/eventhandler.htm>
and <http://resource.dcs.st-and.ac.uk/JavaScript/jsref/evnt.htm>.

I've been trying to polish my Venkman skills, and what I'm finding is that
"routeEvent(Event e)" seems to be returning 'void' all the time... which is odd.
True or false I can understand... but 'void'? Again, it is the *browser* that
defines this function, not the site. So the F_nn_mouseDown function returns
'void' and that, I'm guessing, gets cast to a 'false' and the event is
cancelled. But WHY is 'routeEvent' returning 'void'?! that doesn't make any
sense to me, as I read the JS event handling docs.

Comment 7

[Bob Clary [:bc] (inactive)]

the routeEvent call will return the value returned by whatever event handler
handled the event. As far as I can see, nothing else handled the event so
nothing was returned, ie. undefined was returned.

Comment 8

[andrew]

Hmm. I've filed a bug with the NetObjects people. Something still seems screwy
here... they seem to feel that this script works just swell on NS7 and 4...

Oh well.

Comment 9

[Bob Clary [:bc] (inactive)]

I see the same problem in Mozilla 1.4 and Mozilla 1.7. Since Netscape 7.1 was
based on Mozilla 1.4, I expect it exhibits the same issue.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  routeEvent is a netscape-proprietary DOM0 thingie... it's not
implemented in Mozilla at all (and I doubt we have plans to implement it).  We
have the function defined so you won't get an exception, but it does absolutely
nothing.

It's not implemented in NS7 either, so it'd have the same problem.

This code needs to stop assuming the anything that's "Netscape" is Netscape 4
and anything that's not Netscape 4 is IE (which is what id does right now...)

Comment 11

[andrew]

Netscape-Proprietary?! (much swearing deleted)
I'll email the bug people at NetObjects.

I worked around the bug the following way: in the page's "onLoad" handler, I set
a script to say "document.onmousedown = new Function('return true;');"... and
now my page works just fine.

You know, this is probably an old discussion among developers, but I *really*
dislike "defined but useless" backward compatibility functions. This thing took
WAAAAAY too long to diagnose because of the bogus routeEvent method. If an
exception had been thrown, it could have been caught much faster. I mean, pages
that rely on routeEvent's behaviour aren't going to work anyway...

Ah well.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yeah; maybe we should remove the routeEvent thing... jst?

Comment 13

[Johnny Stenback (:jst)]

The tricky thing to figure out here is how many pages will we break if we remove
it, and how many future pages will be broken if we leave it. So far the thought
has been that it buys us more to just leave them since if the method is there,
it's callable w/o stopping execution of the script (i.e. no "foo is not a
function" exceptions).

Maybe the thing to do is to add a message to the JS console when one of these
stubs are called so that developers have a chance to catch what they're doing?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Bug 242489 filed.

Comment 15

[andrew]

One last question for people:

Does anyone know why adding a document.onmousedown event handler makes the page
work, while without it, the page doesn't?

From what I understand, the routeEvent method is unimplemented, so it should
always return void not matter what.

However, when I set "document.onmousedown = new Function('return true;');" the
page works fine. If I don't set the handler, the mousedown event is cancelled.
Since "routeEvent" should always be returning void, I don't see why this should
happen...

Comment 16

[Boris Zbarsky [:bzbarsky]]

Because that overrides the broken mousedown handler that calls routeEvent to
start with.  So that handler never gets called and doesn't get to cancel the
event.  See /assets/script.js

Comment 17

[andrew]

Thanks Boris - I can't believe I missed such an obvious explanation. Time for
another cup of tea, I think.

Ouch, ouch! My head's going to explode.... AAAAAAAh <Boom!>!

;-)

Cheers,
-Andrew.

Comment 18

[Felix Miata]

Conforming summary to TFM item 10 at 
http://www.mozilla.org/projects/tech-evangelism/site/procedures.html#file-new

Comment 19

[Chris Lawson (gone)]

INCOMPLETE due to lack of activity since the end of 2009.

If someone is willing to investigate the issues raised in this bug to determine whether they still exist, *and* work with the site in question to fix any existing issues, please feel free to re-open and assign to yourself.

Sorry for the bugspam; filter on "NO MORE PRE-2010 TE BUGS" to remove.