Closed Bug 899105 Opened 12 years ago Closed 12 years ago

cannot add new todos in Remember The Milk

Categories

(Tech Evangelism Graveyard :: English US, defect)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: masayuki)

References

Details

Regressed sometime between the 24th and today. When trying to add a new task through the text field, nothing happens after hitting enter. I'm not seeing any errors in the Web Console, either.
(In reply to Ben Hearsum [:bhearsum] from comment #0) > Regressed sometime between the 24th and today. When trying to add a new task > through the text field, nothing happens after hitting enter. I don't understand your report. Could you write actual STR?
Note that if this is a regression on a web site, this should be a tech evangelist bug.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #2) > (In reply to Ben Hearsum [:bhearsum] from comment #0) > > Regressed sometime between the 24th and today. When trying to add a new task > > through the text field, nothing happens after hitting enter. > > I don't understand your report. Could you write actual STR? Sorry, here's a better STR: 1) Login to a Remember the Milk account 2) Click "Tasks" (top right) 3) Click the "add a new task" input field 4) Type a task, hit enter Actual Results: Nothing happens Expected Results: Task should be added to the list below (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #3) > Note that if this is a regression on a web site, this should be a tech > evangelist bug. Yeah, it's not clear that this is, though. It still works fine in Release, and works fine in changes prior to https://hg.mozilla.org/mozilla-central/rev/7c78c3a98313. Could be that we correctly changed something and the website was depending on a bug?
This is making me unhappy as well. Masayuki, assuming we determine that bug 501496 is the regressing changeset, what is the next step? RTM uses gears, so if this is a behavior that Gears gives to all gecko browsers, we may need to back out or alter the behavior of that bug to deal with sites like this. If it's just rememberthemilk, we can probably work with them to get a fix.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > so if this is a behavior that Gears gives to all gecko browsers, we may need > to back out or alter the behavior of that bug to deal with sites like this. Hmm, we have no alternative ways since the new behavior is completely same as all other browsers. If we needed to back it out, a lot of DOM key event bugs becomes harder to fix... I'll check this today.
At breaking in nsDOMEvent::PreventDefault(), the callstack indicates the caller is JS. However, nsXPCWrappedJS::CallMethod()'s info->name shows "handleEvent" for the method name. But I've never found such name in the site. It might be called from Firefox. The listener type is eWrappedJSListener. I'm not sure how to know where is the handleEvent definition.
Er, please ignore the previous comment. The caller of nsDOMEvent::PreventDefault() is untrusted (using nsContentUtils::IsCallerChrome()). The "handleEvent" could be the method of EventHandler interface.
> Utility.prototype.stopEvent=function(A){ > A||(A=window.event); > if(!A){ > return false > } > if(is_ie){ > A.cancelBubble=true; > A.returnValue=false > }else{ > A.preventDefault(); > A.stopPropagation() > } > return false > }; > var E=function(J){ > J||(J=window.event); > > var M=(J.charCode)?J.charCode:((J.which)?J.which:J.keyCode); > var K=((is_safari&&M==25&&J.shiftKey)||M==9); > var H=J.keyCode===38&&(!J.charCode||!J.which); > var I=J.keyCode===40&&(!J.charCode||!J.which); > if(H||M==63232){ > A.list.handleArrowUp(); > A.input.last_enter=false; > A.input.ignore_keyup=true; > utility.stopEvent(J); > return false > }else{ > if(I||M==63233){ > A.list.handleArrowDown(); > A.input.last_enter=false; > A.input.ignore_keyup=true; > utility.stopEvent(J); > return false > }else{ > if(M==27){ > A.list.handleEscape(); > A.input.last_enter=false; > A.input.ignore_keyup=true > }else{ > if(K||M==13){ > A.clearTimeout(true); > A.list.handleEnter(); > if(K){ > A.input.last_enter=true > } > A.input.ignore_keyup=true; > if(!K&&!A.autocommit){ > if(is_ie){ > if(A.field&&A.field._handle_keydown){ > return A.field._handle_keydown(J) > } > } > if(is_safari_31||is_chrome){ > return true > } > utility.stopEvent(J); > return false > }else{ > if(A.field&&A.field._handle_keydown){ > return A.field._handle_keydown(J) > } > return true > } > }else{ > A.input.last_enter=false > } > } > } > } > if(A.field&&A.field._handle_keydown){ > return A.field._handle_keydown(J) > } > }; > > google.maps.event.addDomListener(this.input,"keydown",E); Okay, I believe that this is the site specific problem. The |this.input| is the <input> element which has this bug. |M==13| is the Enter key case (0x0D == 13). See here: > if(is_ie){ > if(A.field&&A.field._handle_keydown){ > return A.field._handle_keydown(J) > } > } > if(is_safari_31||is_chrome){ > return true > } > utility.stopEvent(J); > return false For IE, there is a special path, first. Then, Safari and Chrome don't call utility.stopEvent(J) (J is the keydown event). utility.stopEvent() calls preventDefault().
Assignee: nobody → english-us
Component: General → English US
OS: Linux → All
Product: Firefox → Tech Evangelism
Hardware: x86_64 → All
Version: unspecified → Trunk
Additional evidence: > wg.INSTANCE=null; > > wg.getInstance=function(){ > var A="add-box",J="add-ghost",E="add-helpicon",H="add-label",I="add-spinner",B="add-text",F="smartadd-cheat",D="smartadd-keyclose"; > if(wg.INSTANCE===null){ > wg.INSTANCE=new wg(B,A,J,I,H,F,E,D); > > wg.initializeAutocomplete(); > wg.INSTANCE.initialize() > } > return wg.INSTANCE > }; > function wg(D,J,I,A,B,E,F,H){ > var K=" "; > > this.id_=D; wg.id_ is "add-text". > wg.prototype.enableAutoComplete=function(){ > var A=this; > this.autocomplete_=new Autocomplete(this.id_,this); > function Autocomplete(B,A){ > this.id=B?B:null; > > this.store=A?A:null; > this.bound=false; > this.input=null; > Autocomplete.prototype.bind=function(){ > var A=this; > this.input=el(this.id); So, the |this.input| is <input id="add-text">.
Blocks: 501496
I emailed about this from http://www.rememberthemilk.com/help/contact/?ctx=suggestion But if somebody can contact them officially, please do it.
Hi guys, I'm looking into this on the RTM side. :) Unfortunately the key handling code is pretty hairy since it works back to IE6 and Gecko 1.8. I was probably just relying on a particular Gecko quirk. Will update once I've tracked it down. Thanks!
This should be fixed on our (RTM) end. Please let me know if there are any other key handling issues. Thanks again for getting in touch with us. :)
omar.kilani: Thank you! I confirmed that it's fixed by your side!!
Assignee: english-us → masayuki
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.