Closed Bug 313940 Opened 15 years ago Closed 14 years ago

Caret leaves artifacts (turds) on a form when a CSS margin is present

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cochonou, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; fr; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; fr; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

On FireFox 1.5 Beta2 on Mac, the input text caret for forms leaves artifacts when there is a CSS margin present. The blinking might also be incorrect.
The behaviour seems dependent on the margin width and the actual width of the window.

See the included testcase for a better demonstration.

This might be related to bug 287813, however as I have been unable to reproduce it under Linux it might be mac-specific.

Reproducible: Always

Steps to Reproduce:
See the testcase information.
Attached file Testcase
I'm seeing this on Firefox builds as far back as 2004-04-16 (4 days after the 1.7 branch). I'll keep investigating.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Strange. This seems to have been broken on the trunk forever (at least ince the Firefox 0.8 days), but it is fixed in the first 1.7 branch build I coulld find (from 2004-05-30), suggesting it was somehow fixed early on that branch but never on the trunk.
... but I'm not seeing the problem on SeaMonkey builds!

I'm really not sure what to make of this.
Please ignore my previous comments. With correct resizing of the window, I can see it both in Firefox 1.0 and in current SeaMonkey builds.

So this is not a regression of any type. Just an old problem.
Attached file testcase #2
This testcase shows the problem regardless of window width.
With the inner (red) div styled "width:50%; margin:auto;", the problem occurs whenever the pixel-width of the outer div is odd (but not when it's even).

So this is almost certainly some kind of rounding problem. The fact that BRFrames have a 1px width might also have to do with it.
Confirming, since I can't find a dupe.
Also adding "turds" to the summary for easy finding.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Caret leaves artifacts on a form when a CSS margin is present → Caret leaves artifacts (turds) on a form when a CSS margin is present
Keywords: testcase
Camino seems to be unaffected by this bug, at least since version 1.0 alpha. 
Bug 315831 depicts a similar behaviour when turning on caret browsing.
The second problem described in the testcase ("The caret blinks incorrectly, alternating between the familiar | and a stray point.") seems to be fixed by the fix to bug 287813.
The first problem remains.
Blocks: 345640
OS: Mac OS X 10.2 → All
Hardware: Macintosh → All
This could very well be fixed by the patch in bug 335065, so please test again with current trunk build.
Indeed, this seems FIXED on Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20061126 Minefield/3.0a1
I will test on Windows/Linux later.
Came across this bug in two instances:

1. www.digg.com/news login control
2. www.amazon.com search control

See screenshots:
http://tinypic.com/view.php?pic=4xzf0qd
http://tinypic.com/view.php?pic=4yk16ch

This appears to only affect Gran Paradiso 3.0a4 and Minefield 3.0a5pre on Windows XP.  I could not get this bug to reproduce on Mac or Vista.

The bug only happens on digg when the window is not maximized.  The bug happens on amazon whether the window is maximized or not.  Also, this bug happens on both new and existing profiles.
Upon further testing I have discovered that the caret artifacts are mimicking the background colour/image of the form.
Anthony, could you file a new bug on that?
This bug is probably already fixed now, or can you reproduce it still with current trunk build with the testcases?
Marking as FIXED, I can't reproduce this anymore.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The issue mentioned in comment 13 was filed as bug 381792.
You need to log in before you can comment on or make changes to this bug.