Closed Bug 618921 Opened 14 years ago Closed 13 years ago

the chat capability of etherpad application doesn't work with fennec

Categories

(Firefox for Android Graveyard :: General, defect, P2)

ARM
Android

Tracking

(fennec-)

RESOLVED FIXED
Firefox 11
Tracking Status
fennec - ---

People

(Reporter: mevans, Assigned: alexp)

Details

(Whiteboard: [vkb][hkb])

Attachments

(1 file, 1 obsolete file)

created a etherpad @ www.ietherpad.com, the chat text area on the right allows the user to submit a line of text with the the input of the carriage return as the event to submit the text. 

This doesn't work in fennec, how works fine with the android browser.
Since the page uses XMLHttpRequest, it would be worth grabbing NSPR logs to see if everything's behaving correctly.
flagging for blocking final
tracking-fennec: --- → ?
can't reproduce, please reopen if you have STR that work on a recent build
Status: NEW → RESOLVED
tracking-fennec: ? → 2.0-
Closed: 14 years ago
Resolution: --- → WORKSFORME
1) go to: http://mozqa.ietherpad.com/3
2) enter text into the lower right text box labeled "chat"
3) press return

Nothing happens.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #4)
> 1) go to: http://mozqa.ietherpad.com/3
> 2) enter text into the lower right text box labeled "chat"
> 3) press return
> 
> Nothing happens.

what build? what device? what keyboard?
1. fennec beta3 build 3
2. Samsung Epic
3. Both physical and virtual keyboards are affected
works fine for me too on nexus one and samsung galaxy tab. The only problem I see is the textbox is panned out of view. If I pan it back into view, I can see the text being entered and then added to the chat window when I press "enter" key.

At one time, I did see an issue where the text being entered into the textbox was underlined - pressing enter or submit would not post the text the chat window. In that case I had to "commit" the text to the textbox first, then it all worked.
OS: Mac OS X → Android
Hardware: x86 → ARM
The problem is in the way how we enable the IME for that Etherpad chat field. IMEContext.mActionHint is "next", so we replace Enter with Tab in GeckoSurfaceView.processKeyDown.
Summary: the chat capability of etherpad application doesn't work with fennec on Samsung Epic → the chat capability of etherpad application doesn't work with fennec
Attached patch Fix (obsolete) — Splinter Review
Provide "next" action hint only for the form.

Brad, will you review your own change :) or should the component owner have a look?
Assignee: nobody → alexp
Status: REOPENED → ASSIGNED
Attachment #570405 - Flags: review?(blassey.bugs)
Comment on attachment 570405 [details] [diff] [review]
Fix

as you said, this is my code. Smaug, can you review?

The idea here is that if there isn't a form, we don't know that there won't be a submit on enter and we don't know that there will be another input item to "tab" to, so we should just revert to having a return key on the keyboard.
Attachment #570405 - Flags: review?(blassey.bugs) → review?(Olli.Pettay)
Comment on attachment 570405 [details] [diff] [review]
Fix

># HG changeset patch
># User Alex Pakhotin <alexp@mozilla.com>
># Date 1319843705 25200
># Node ID c280a1785a34b05868bcba92743d8e8a18af023c
># Parent  bdaf276850c67083d78c0b353f0dfdfd3ce4b43d
>Bug 618921 - the chat capability of etherpad application doesn't work with fennec
>
>diff --git a/content/events/src/nsIMEStateManager.cpp b/content/events/src/nsIMEStateManager.cpp
>--- a/content/events/src/nsIMEStateManager.cpp
>+++ b/content/events/src/nsIMEStateManager.cpp
>@@ -310,33 +310,39 @@ nsIMEStateManager::SetIMEState(PRUint32 
>       aContent->GetAttr(kNameSpaceID_None, nsGkAtoms::type,
>                         context.mHTMLInputType);
>       aContent->GetAttr(kNameSpaceID_None, nsGkAtoms::moz_action_hint,
>                         context.mActionHint);
> 
>       // if we don't have an action hint and  return won't submit the form use "next"
>       if (context.mActionHint.IsEmpty() && aContent->Tag() == nsGkAtoms::input) {
>         bool willSubmit = false;
>+        bool hasNext = false;
>         nsCOMPtr<nsIFormControl> control(do_QueryInterface(aContent));
>         mozilla::dom::Element* formElement = control->GetFormElement();
>         nsCOMPtr<nsIForm> form;
>         if (control) {
>           // is this a form and does it have a default submit element?
>           if ((form = do_QueryInterface(formElement)) && form->GetDefaultSubmitElement()) {
>             willSubmit = true;
>           // is this an html form and does it only have a single text input element?
>           } else if (formElement && formElement->Tag() == nsGkAtoms::form && formElement->IsHTML() &&
>                      static_cast<nsHTMLFormElement*>(formElement)->HasSingleTextControl()) {
>             willSubmit = true;
>           }
>+          if (formElement && formElement->Tag() == nsGkAtoms::form)
>+            hasNext = true;

if (expr) {
  stmt;
}

Why formElement->Tag() == nsGkAtoms::form ? What else could a form element be?
So, I don't see any need for hasNext. Just use formElement.



>         }
>         context.mActionHint.Assign(willSubmit ? control->GetType() == NS_FORM_INPUT_SEARCH
>                                                   ? NS_LITERAL_STRING("search")
>                                                   : NS_LITERAL_STRING("go")
>-                                              : NS_LITERAL_STRING("next"));
>+                                              : hasNext
>+                                                  ? NS_LITERAL_STRING("next")
>+                                                  : NS_LITERAL_STRING(""));
>+
I guess you need NS_LITERAL_STRING("") here, but in general EmptyString() is preferred.
Attachment #570405 - Flags: review?(Olli.Pettay) → review-
Attached patch Fix 2Splinter Review
Addressed review comments.
Attachment #570405 - Attachment is obsolete: true
Attachment #570431 - Flags: review?(Olli.Pettay)
Comment on attachment 570431 [details] [diff] [review]
Fix 2

Please push the patch first to tryserver to make sure
EmptyString() works in this case.
If it doesn't, use NS_LITERAL_STRING("")
Attachment #570431 - Flags: review?(Olli.Pettay) → review+
Thank you for a quick review, Olli.
Pushed to try.
hg.mozilla.org/projects/birch/rev/9f5570d58bca
Status: ASSIGNED → RESOLVED
Closed: 14 years ago13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: