User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6 Use your mouse to select some text in the appended HTML file; usually 2-3 tries are enough to see the effect. You will recognize, that sometimes selected text (and neighbouring chars, too) is going to be underlined with 1px and sometimes ca. 5px and will stay underlined even though you un-selected the text. I see absolutely no reason for this behaviour. Does not happen in Opera for example. Reproducible: Always Steps to Reproduce: 1. select some text 2. select other text 3. always look at the text ;) Actual Results: text gets and sometimes stays underlined Expected Results: text shall stay un-underlined

I can't reproduce using latest trunk/branch on Linux.

I can't reproduce this on the 1.8.0.6 build nor with the latest trunk build on windows.

(In reply to comment #4) > I can't reproduce this on the 1.8.0.6 build nor with the latest trunk build on > windows. I just testet it again in safe mode, happens as well => is not caused by any extension. I did not mention it's Win XP Pro Tablet PC edition, in case this makes a difference (which I doubt).

I can confirm it on seamonkey trunk build 2006080809, windows xp pro. While selecting [keeping the mouse button down] a "Frage" row and extending the selection to the "Meta-infos" row, some of the cells' text becomes underlined ("Fach" or "ABWL" for example). Often, it will stay underlined after releasing the button and ending selection. It doesn't always happen nor did I understand the mechanics of why it happens, but something's definitely there. Note: I did not analyse the page source.

It's not related to selection but to a redraw issue, I believe. Steps to Reproduce: 1. open the simplified testcase provided 2. open some other window [I used calc.exe] 3. drag the 2nd window over the testcase vertically, from down to top, as smoothly as possible [1px at a time] Result: The first row cell gets a new "border" in the redrawn areas below the dragged window. If you remove the border-bottom style for the last row, the bug disappears.

(In reply to comment #7) > 3. drag the 2nd window over the testcase vertically, from down to top, as > smoothly as possible [1px at a time] Remark: You have to have enabled "show window content when moving window" (literate translation back to english) in Windows, settings, display, appearance, effects. I can confirm that behaviour.

Forgot to mention that you can easily reproduce the original erratic selection behaviour by selecting the text in the first row.

This bug is filed against 1.5x or at least this is in the reporter's UA, but I can only reproduce it in cairo enabled trunk builds.

Thanks for the simplified testcase, I can see the bug on Firefox1.5.0.6 and current trunk builds now. I think this is more a layout:tables bug, because of the use of border-collapse in the testcase.

this works in my debug build

The patch from bug 452319 fixes this I pushed the testcase http://hg.mozilla.org/mozilla-central/rev/3e4ca31ff5fb