User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b5) Gecko/20100101 Firefox/4.0b5 I cannot define a signature in gmail. Reproducible: Always Steps to Reproduce: 1. Go to your gmail account 2. Click "Settings" on the top right of the windows 3. Try to enter a signature Actual Results: The cursor doesn't stay in the field, impossible to enter any text Expected Results: The text should be written in the windows This has been confirmed by some other users on french ubuntu forums here: http://forum.ubuntu-fr.org/viewtopic.php?pid=3714408#p3714408 Seems to be a regression because it works without problems with Firefox 3.6.x

Confirming bug is still there, Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101120 Firefox/4.0b8pre

I have the same problem Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101123 Firefox/4.0b8pre

I'm affected by this bug to, using latest nightly. Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101125 Firefox/4.0b8pre

In fact, you can enter text, but you must keep the mouse button down...

Still there with beta 9. Does anyone care about this issue?

(In reply to comment #5) > Still there with beta 9 and also beta 10...

And also with beta 12 pre. :(

i have the same issue with 4.0b12pre (2011-02-16) on linux and 4.0 beta 11 on windows XP

I'm popping to editor to get this out of the Firefox general black hole. This is easy to reproduce on the latest nightly on Mac OS X. You cannot focus the signature editor component. Focus moves to the radio button

do we think this is a site problem where some evangelism is needed, or firefox regression? probably needs to block until we know more.

Confirmed using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre ID:20110216030352 Last good nightly: 2010-05-03 First bad nightly: 2010-05-04 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=83c887dff0da&tochange=d6bb0f9e9519

358113b3642e Henri Sivonen — Bug 373864 - Enable the HTML5 parser by default. r+sr=js ? Does this go away if you disable HTML5 parsing? I wonder if this is broken browser detection on gmail's part, similar to the Hotmail ad refresh evang bug that is currently blocking.

Toggling html5.enable to false makes this go away. But this doesn't make much sense. Investigating more closely.

The editor doesn't seem to be at fault here... The only difference that I observed with the HTML5 parser enabled is that when the iframe is focused using the keyboard (which works correctly), the class name of the parent div of the iframe changes to "Ad Au Ao" (from "Ad Au"), and when you try to focus the box using the mouse, when the mouse is down the class name changes, and when you release the mouse it reverts back to its previous value. The class name itself is not significant, but maybe there's some js code failing somewhere in the middle of the way because of the differences in the DOM produced by the parser?

(In reply to comment #0) > Steps to Reproduce: > 1. Go to your gmail account > 2. Click "Settings" on the top right of the windows > 3. Try to enter a signature > Actual Results: > The cursor doesn't stay in the field, impossible to enter any text I can't reproduce with these steps. (In reply to comment #13) > I wonder if this is broken browser detection on gmail's part, Could someone who can reproduce the problem please set general.useragent.override to Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.45 Safari/534.16 and see if the problem goes away?

(In reply to comment #16) > (In reply to comment #0) > > Steps to Reproduce: > > 1. Go to your gmail account > > 2. Click "Settings" on the top right of the windows > > 3. Try to enter a signature > > Actual Results: > > The cursor doesn't stay in the field, impossible to enter any text > > I can't reproduce with these steps. You may need to have a signature saved already. With that, go to the settings page, scroll down to the edit signature field, and click on it using the mouse to focus it. It's quite easy to reproduce (on Mac at least). > (In reply to comment #13) > > I wonder if this is broken browser detection on gmail's part, > > Could someone who can reproduce the problem please set > general.useragent.override to Mozilla/5.0 (X11; U; Linux x86_64; en-US) > AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.45 Safari/534.16 and see > if the problem goes away? Using he chrome UA string causes gmail to send us code which doesn't work at all. I get an unstyled iframe, and it doesn't seem that we run any js code in that situation, so it's impossible to tell whether masquerading as another UA helps or not.

Now I see this. First, I got an old version of Gmail. When I logged out and back in, I got a new version ("Settings" no longer text in the top left corner but behind a cog icon) that shows the problem.

With the HTML5 parser, the signature editor ends up inside the <label> for the radio button above it, so events in the subtree move the focus to the label. With the old parser, the signature editor doesn't end up inside the label. So far unclear what the unparsed source HTML looks like.

The parser explanation is that in Firefox 3.6, unlike in every other browser, <div> implicitly closes <label>. Given that the HTML5 parser made Firefox do what everyone else does, I think it doesn't make sense to treat this as a parser bug. The next question is if it would make sense to change Gecko's event response behavior in subtrees rooted at <label>. Consider http://software.hixie.ch/utilities/js/live-dom-viewer/saved/838 In Opera 11.01 and in IE9 RC, clicking the textarea doesn't check the radiobutton. In Chrome 10 and Safari 5 it does, but the focus doesn't move to the radiobutton. In Firefox and (surprisingly) in Midori, clicking the textarea checks the radiobutton and moves focus to it. I guess we should not make <label> move the focus to the form control it labels when another form control within the same <label> is clicked. The behavior is underspecified in the WHATWG HTML spec.

We already have a bug about that: bug 213519. According to Hixie's comment [1], the specs were changed (in 2004) to make events sent to form controls directly managed by the form control itself even if inside a label but I can't found anything related to that in the current specs. I think we should make this bug an evang bug because whatever happen, it will not be done for Firefox 4. In the meantime, i will try to bring this issue to the WHATWG list. [1] bug 213519 comment 13

Moving over to evang. kev, could you use your channels to bring Gmail team attention to this?

Email sent this morning to the Gmail team pointing out the issue. If I get an update, I'll post it here.

(apologies for bugspam - moving back to a component where I can clear the blocking flag)

Restoring assignee.

I do not reproduce the problem anymore. I think it is solved (by Gmail team?).

Seems fixed to me as well.

Is resolved now for me using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110315 Firefox/4.0b13pre ID:20110315030415 Last time I noticed it wasn't working was ~1-2 weeks ago, so has been fixed between then and now by gmail.

Indeed, it has been fixed by GMail. Marking the bug WFM then.

Oups, I didn't see it has been moved to an evang bug. FIXED is actually better then.

it works for me now