Closed Bug 290131 Opened 19 years ago Closed 18 years ago

can't write to editbox at dict.sztaki.hu

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fejesjoco, Assigned: aaronlev)

References

(
URL
)

Details

(Keywords: helpwanted, regression) 

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

it worked with 1.7.5. now it doesn't work with 1.8b1, i can't write to the word
search editbox.

Reproducible: Always
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050413
Firefox/1.0+

WFM
This works for me with GTK2 builds, but NOT GTK1 builds.  It regressed between
2005-01-18-07 and 2005-01-19-08 builds.  Looking at the checkins (and the page),
looks like the culprit is bug 167145.

The markup on the page has:

  <input type="text" name="W" style="width:180" class="search" size="25"
   value=""onKeyDown="handleKeyDown(); return false" 
   onKeyUp="handleKeyUp(); return false">

so I'm not sure why this is working at all with some toolkits (and why it's
working in IE, if the comments in bug 167145 are correct).
Assignee: general → events
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → Trunk
Aaron, this is all yours.
Assignee: events → aaronleventhal
Flags: blocking1.8b3?
Keywords: regression
Blocks: 167145
It looks like that in IE
return false; consumes the event
return true; unconsumes the event
return; does not affect consumption
Hmm... so do we want to emulate that behavior?  Or will that break pages?
In fact, unconsuming the event is the default action; only "return;" and "return
false;" have special actions. bz also asked me to compare keypress events. In
IE, the keypress does not fire if the keydown was consumed. If the keypress does
get fired, then the weird consumption model applies.
Ian, you may be interested in this, as long as you're working on the "HTML5
should be whatever IE does" model...
I don't understand the description of what IE is doing.

The current text in the HTML5 spec for how to do event handlers is:
   http://whatwg.org/specs/web-apps/current-work/#event
...which sounds a lot simpler.
(Specifically, what does "unconsume" mean in terms of the DOM events model?)
"unconsume" can't be expressed in terms of the DOM event model, really.  It
corresponds to having an allowDefault() method which can be called to override
an earlier preventDefault() call.

What IE is doing is that

  <body onkeydown="return true;">
   <input onkeydown="return false;">
  </body>

allows the default action of the keydown to happen.
Wow, ok, weird. I have no plans on specifying that in HTML5, since it would
require changes to the DOM Events model. I'm surprised that this is the first
time we've run into that though; I'd have thought we'd have hit this more often
if it was commonly used.
If this is the first we hear about this i'd rather just leave it alone
This is a DOM quirk I'd rather we didn't emulate.  What other sites depend on
it?  How about evang for now?

/be
FYI I counted not explicitly returning as equivalent to "return;"
I guess nested event handlers aren't common.

But are you sure about this? I recently tested stuff in IE where I had nested
handlers and the last handler to fire didn't do a "return" at all (which
according to you should reset any effect done by an earlier event handler), yet
I could make the behaviour change by return a different value in a deeper
(earlier) event handler.
What is the final summary of what we do the same/differently from IE? I know
that both IE and Mozilla handle the true and false return values the same as IE,
and cancel the keypress for a cancelled keydown.

Is the difference we talking about in this bug only what Boris brings up in
commment #10 -- nested keydown handlers that return different values?
Yes, the problem is that this site cancels the keydown at the textbox, then
uncancels it at the body in IE.  So in IE you can type in the box, and in
Mozilla you can't.
(In reply to comment #17)
> Yes, the problem is that this site cancels the keydown at the textbox, then
> uncancels it at the body in IE.  So in IE you can type in the box, and in
> Mozilla you can't.

So is the consensus that this is an evangelism issue, e.g. fix the site?
Blocking- per apparent consensus that this is notabug, but an evangelism issue.
Please renominate for 1.8b4 if this is incorrect.
Flags: blocking1.8b3? → blocking1.8b3-
Well.  This is a regression from implementing part but not all of some IE compat
stuff.  The question is whether we care for full compat here, basically.
We should sort this out.  If we plan not to do full IE compat here, we need devmo documentation on the subject.
Flags: blocking1.8.1?
(This specific problem doesn't exist anymore on the given url, because they changed their code)
Keywords: helpwanted
Not going to block 1.8.1 for this bug.
Flags: blocking1.8.1? → blocking1.8.1-
Why bother.  This is clearly wontfix-by-apathy.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
You don't think it's a TE bug?
If someone's willing to own it, sure.  As far as I can tell, TE is more or less a black hole...
More of a black hole than WONTFIX?  I'll try to reassign to the appropriate part of TE this weekend, once I get a moment to determine which part that is.  Someone should feel more than free to beat me to it.
You need to log in before you can comment on or make changes to this bug.