User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060618 Camino/1.2+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060618 Camino/1.2+ Noticed when using the Google Translate site. After a string has been translated, there are two textareas on the page: one with the translated text followed by one with the original. If the first textarea contains a misspelled word, the second textarea displays with a dotted border. I noticed this because Google use US English while my OS X spell checker (used by Camino) uses British English. Regression: Works fine in the 2006061704 trunk build Fails (dotted border) in the 2006061805 build It also happens here on Bugzilla, while filing this bug Reproducible: Always Steps to Reproduce: 1. Set your OS X spell checker dictionary to something else than US English (e.g. British English) 2. at Google translate, translate this string 'reconnaître la possibilité' from French to English 3. Watch the spell checker flag an error in the word 'recognize' in the textarea at the top (correct US-en, but British English spells it as 'recognise') 4. watch the second textarea display with a dotted border. Actual Results: Dotted border around subsequent textarea (sort of like the focus-ring) Expected Results: solid border on the textareas I already filed bug 341317 for similar behaviour in Firefox. The behaviour in Firefox requires form controls to have a border specified in stylesheets. This may be the same, Camino uses a custom stylesheet (forms.css) that specifies borders on textarea, different from the default. Scrolling the page up and down (here on the bugzilla page) restores the correct display (solid border), something that does not happen in Firefox.

The spell checker stuff got hooked up in Camino between 20060617 and 20060618. Bug 151040

I was able to repro this with the 18 June nightly on the same site. I'm not sure exactly *how* the spellcheck checkins changed this, but it appears they did. cl

Test case, two textareas. The first one is pre-filled with a word that should be wrongly spelled in most languages.

Can we add the regression keyword on bona fide date-proven regressions, please ;) Checkins based on philippe's comment range: http://tinyurl.com/s2xro I'll agree that nothing else in there seems to make sense, but I've also seen this happen to textareas with no content <http://bugzilla.abisource.com/show_bug.cgi?id=10105> (and to select multiples, but I forget where now) in my recent random trunk use. This also does not seem to manifest itself on the branch with spelling, so it must be something trunk-specific interacting with spell-checking (or spell-checking is a red herring altogether). philippe, if you hack firefox's forms.css to have borders on textareas (or build cocoafox), do you see the same issue?

(In reply to comment #5) > ...... > > I'll agree that nothing else in there seems to make sense, but I've also seen > this happen to textareas with no content > <http://bugzilla.abisource.com/show_bug.cgi?id=10105> (and to select multiples, > but I forget where now) in my recent random trunk use. I still haven't been able to repro it with select[multiple] or select[size="xx"], or with empty text areas. Something I can do consistently with my hacked up forms.css in Firefox. If you remember where you saw those select multiples giving problem please tell. > > This also does not seem to manifest itself on the branch with spelling, so it > must be something trunk-specific interacting with spell-checking (or > spell-checking is a red herring altogether). All symptoms point to the same problem as bug 341317, but, as I noted above and in comment #0, so far I haven't been able to repro the problem with Camino (and CocoaFox, btw), except, and consistently, with spellchecking underline. > > philippe, if you hack firefox's forms.css to have borders on textareas (or > build cocoafox), do you see the same issue? My hacked-up forms.css in Firefox is how I actually discovered the issue(s), and filed bug 341317 :-). I filed this one for Camino, because I wasn't sure if the root cause was actually the same. The little border coming from spellchecking is so far the only trigger in Camino for me.

I just saw the select multiple on the branch, in the cc list for bug 339186. One time it looked like it was trying to spellcheck the select (briefly underlining sam's domain) and another time it underlined the reporter's last name (which is pure non-form HTML!) and then converting the select's border to dots. (I can't see the underline flashes on the trunk, just the dotted results). So far I've only been able to reproduce this with layout.spellcheckDefault set to 2 (single and multi-line text fields); simply toggling between 1 tab with the bug and 1 tab with about:config and toggling the pref values seems to cause the dotted border. So the selects may actually be a slightly different bug. The AbiBugzilla case I still see only on the trunk.

(In reply to comment #7) > I just saw the select multiple on the branch, in the cc list for bug 339186. > One time it looked like it was trying to spellcheck the select (briefly > underlining sam's domain) and another time it underlined the reporter's last > name (which is pure non-form HTML!) and then converting the select's border to > dots. (I can't see the underline flashes on the trunk, just the dotted > results). With layout.spellcheckDefault set to 2, I can indeed reproduce this. The select[multiple] box has indeed a dotted border. Noticed that bug 339186 has an alias (tibco) which activates the spellchecking. Strangely, the simple test case attached here doesn't trigger the bug on branch/10.3.9. And trying out Google translate as in comment 0 doesn't trigger this on branch/10.3.9. (and while typing this, this textarea has a dotted border... I just scrolled up/down). > > So far I've only been able to reproduce this with layout.spellcheckDefault set > to 2 (single and multi-line text fields); simply toggling between 1 tab with > the bug and 1 tab with about:config and toggling the pref values seems to cause > the dotted border. So the selects may actually be a slightly different bug. > Setting layout.spellcheckDefault to 2 makes it just more visible. As a little exercise, I changed the Camino default forms.css, erasing the custom borders on widgets (input, textarea, select). Sure enough, the problem was gone. I then applied custom borders to textarea, input, etc in a linked stylesheet. Back it is. I'm more and more convinced that this is the Camino version of bug 341317. That bug is much harder to see on Camino, due to the Cocoa Widgets, and so far, as I've said before, I can only trigger it in Camino when the spell checker does its job. I suspect the code that triggers/paint the dotted underline (and in Core it uses the css border property, afaik) is doing something fishy... PS - bug 341317 started after the 20060524 build.

could this have to do with the gfx code setting attributes on the pen state in quickdraw that aren't getting correctly cleared by the time gecko wants to draw the form controls? i was a bit worried about that on josh's patch initially, maybe that's what's going on here...

The Fx equivalent of this bug started right after that patch landed; see bug 341317. We start seeing this at a different time since spelling didn't land until later for us, but I bet if someone pulled by date and added the Cm-spell stuff, this would be a red-handed dupe.

Josh's code is right. Someone's using the same rendering context to draw the textarea as was used to draw the dotted line, but nobody's ever calling SetLineStyle to restore the original line style or set it to solid.

Same cause. *** This bug has been marked as a duplicate of 341317 ***