missing cursor in browser text fields

[walter]

I thought I had already filed this ticket, but it seems to have gone into the bit bucket.

I've experienced three different behaviors with the browser on Build 650 (ship.2) -- all in the same login session, different launches of the Browse activity:

(1) no cursor and no ability to type into a text field (2) no cursor but you can type into the text field (3) cursor and you can type into the text field

Of course, Behavior 3 is the desired behavior.

To reproduce, try to compose a message in gmail. You should be able to see the cursor in the To and Subject fields. The Body field is where this intermittent problem occurs.

[erikos]

650:

• I could reproduce what walter described in the body box in gmail the first try
• was able to send use two other email web interfaces just fine
• was able to use wikipedia sandbox fine as well

joyride (1371):

• was able to use gmail to send a mail

mozilla3.0

• fine here as well to use the gmail web frontend

[walter]

The cursor problem seems to be related to rich text boxes, not plain text boxes, which explains the intermittemt behavior re #2 and #3 above. Dont know how to reproduce #1 above.

[erikos]

At the moment I have problems to reproduce 1. I had it directly when tested the first time. More testing tomorrow.

[erikos]

I am not sure what (2) means. Does this mean the cursor change to a | when hovering over a text field.

I had the behavior described in (1) only one time yesterday on 650 after an upgrade from 643. Since then I can not reproduce it. Tried as well on 643, reflashed 650 several times etc. Removed gnash, installed flash(since there was a gnash error in the log), tested without gnash and flash - without any luck to reproduce. I was always able to use the text field. So this gnash error was not related to the problem.

It seams I can not find a way to reproduce it yet.

[jg]

The text field in gmail is to input complex text (e.g. bold, or other formatting). (straight ascii works fine).

[erikos]

Thanks Jim. It came up as plain text - that is why it worked and I did not remember the plain text thing part. So yeah I still see the cursor when hovering over the text box - but i can type in and use the rich text options to modify my input.

[erikos]

Ok I think I nailed it down as:

(2) is the behavior we see on a ship.2 build (e.g. 650) When you are in rich text mode and you hover over the text box you will see the cursor not the text cursor(caret). When you actually click in the text box you can type some text. But you do not see the caret to know at which place you actually are in the box which is the irritating part. In the plain text mode on a ship.2 build the cursor will change to the caret once you hover over the text box. BTW: I could reproduce this behavior on sugar-jhbuild which has as well an older xulrunner version.

(3) is the behavior I have seen on a current joyride build (e.g. 1377) and mozilla3 and mozilla2. In rich text mode when you hover over a box it stays a cursor, but once you click the caret is indicating the position in the text box and you can type your text away.

(1) actually while typing this I can see this behavior as well on my ship.2 machine. plain text mode works in this test sample but rich text does not. I see the cursor, the caret is not displayed when I click in the text box and I can not fill in text. As well when I try to select for example the modifier bold the toggle button gets deselected immediately.

[erikos]

Note:

2) On 650 I tested as well another mail web-interface. I had the same symptom than described in behavior 2 in comment 8. So likely not dependent on the gmail rich-text field.

1) I tried to tab to the text box. I only got the text field with a _ _ _ dotted border. And when I tabbed again the border was gone. As well zooming out and switching to another activity and back did not reveal the curse. When I did go to another web page and the back to the gmail interface in the same browser session I had behavior 2 again.

[erikos]

Since on joyride, which has a newer browser vesion (xulrunner), I always had the behavior (3) I installed the latest xulrunner-1.9-0.beta1.6.olpc2 on a 650 build. Since now I could always reproduce the desired beavior (3) on this build.

I am mostly worried about behavior (1) and will try hard if I can get this with this modified 650 build.

[erikos]

I do not see this error with the latest xulrunner (joyride 1422). Getting this into the build is handled by #5041.

[erikos]

Tested in 661 as working with gmail rich-text field and with another web interface with a rich text field.

Please reopen if someone see this again in a version >= 661.