Closed Bug 381792 Opened 18 years ago Closed 18 years ago

Caret leaves artifacts on a form

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: u279076, Assigned: sharparrow1)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(3 files)

JAR file needed for loading the testcase (Load URL)
3.88 KB, application/octet-stream
Details
Testcase: Copy of Digg Login Control
32.27 KB, text/html
Details
testcase2
1004 bytes, text/html
Details
This bug is possibly related to bug 313940, however it cannot be reproduced in either of the test cases: "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." I came across this bug in three instances: 1. www.digg.com/news login control 2. www.amazon.com search control 3. www.tomshardware.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. This bug does not happen on the 2 test cases from bug 313940. Steps to Reproduce: 1. Visit www.digg.com/news 2. Click on "login" 3. Start typing in the "username" or "password" fields or 1. Visit www.amazon.com or www.tomshardware.com 2. Start typing in the search field
This seems like it'd have to be a bug in form control drawing or something. The caret no longer erases itself, it simply invalidates the area that it was currently at and doesn't draw when asked to (sort of, that's the general idea). I don't see how the background of the form could peek through the textarea, though.
I suspect this regression was caused by bug 177805. Build 2007-02-06 of Firefox trunk works (Vista) but build 2007-02-07 displays this bug.
No longer blocks: pixels
If someone could attach a testcase that shows the problem to this bug so we could be sure that it won't suddenly disappear due to a site redesign, that would be very nice.
Flags: blocking1.9?
Good idea Boris. I would like to add that the form fields are not simple html and that simple html fields are unaffected by this bug. I am not quite sure how the above sites generate their forms. I believe digg might use php, but I am not 100% sure on that. Also, javascript forms are not affect by this bug. Then again, it may be something else being used, common to the three sites, completely unrelated to the forms that is causing this issue. Just some food for thought.
The point is, it should be someone who can actually reproduce the bug. This worksforme on digg, for example... Then again, digg has at least two different "login" links on that news page, that do totally different things, so maybe I was looking at the wrong one? Again, that problem would be resolved by having a testcase in the bug. I doubt PHP has anything to do with this, but the stylesheets attached to the page probably do, as does the script and HTML.
Agreed. It is probable a combination of things going on. Just for your reference: For digg, I tested on the login control that is placed at the top right of the page.
Anthony, I guess my point was that if you have the time to do it, it would be great if you'd attach such a testcase...
I am not sure I would be able to make a testcase without stealing a copy of Digg or Amazon. This seems to be a fairly niche set of circumstances required to reproduce this bug.
The point would in fact be to "steal" a copy (e.g. via "save page, complete") and attach it to this bug if the result shows the problem.
There is no legal concerns with that?
I do not feel comfortable doing that.
It's standard operating procedure for bug reports, frankly. As far as I know this falls under fair use no matter how you slice it. And it's the only way to get this bug fixed, I suspect.
While not _completely_ minimal, the testcase I've posted in the URL is a start.
Here is a testcase (re: digg login control). I pasted in the css and removed everything that appeared not to be needed to cause this bug. Just launch the html file and try typing in the username or password fields. You should see the background bleeding through before the 1st character and after the cursor.
(In reply to comment #15) > Created an attachment (id=268541) [details] > Testcase: Copy of Digg Login Control > > Here is a testcase (re: digg login control). I pasted in the css and removed > everything that appeared not to be needed to cause this bug. Just launch the > html file and try typing in the username or password fields. You should see > the background bleeding through before the 1st character and after the cursor. > OK, this attachment I just uploaded does not reproduce the bug, but it does if I use it anywhere else (other than bugzilla)
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=268541) [details] [details] > > Testcase: Copy of Digg Login Control > > > > Here is a testcase (re: digg login control). I pasted in the css and removed > > everything that appeared not to be needed to cause this bug. Just launch the > > html file and try typing in the username or password fields. You should see > > the background bleeding through before the 1st character and after the cursor. > > > > OK, this attachment I just uploaded does not reproduce the bug, but it does if > I use it anywhere else (other than bugzilla) > I uploaded a copy to ashughes.50webs.com/Digg%20_%20.htm Sometimes it works, sometimes it doesnt from there. But the bugzilla test case always works. Needless to say I am highly confused.
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=268541) [details] [details] > > Testcase: Copy of Digg Login Control > > > > Here is a testcase (re: digg login control). I pasted in the css and removed > > everything that appeared not to be needed to cause this bug. Just launch the > > html file and try typing in the username or password fields. You should see > > the background bleeding through before the 1st character and after the cursor. > > > > OK, this attachment I just uploaded does not reproduce the bug, but it does if > I use it anywhere else (other than bugzilla) > I uploaded a copy to http://ashughes.50webs.com/Digg%20_%20News.htm Sometimes it works, sometimes it doesnt from there. But the bugzilla test case always works. Needless to say I am highly confused.
I have discovered that I dont see the bug if I run Minefield in safe mode. I checked my addons and I only have (or had) Talkback and DOM Inspector installed. The following test conditions all created the bug: 1. Disable DOM Inspector, Enable Talkback 2. Disable DOM Inspector, Disable Talkback 3. Uninstall DOM Inspector, Disable Talkback 4. Uninstall Talkback and DOM Inspector
New profile fixed the bug. Since I was testing before on a new-ish profile, I will play around with history, bookmarks, rss, password manager to try to reproduce the bug.
So removing any part of that CSS makes the bug go away for you?
Attached file testcase2 —
For some reason, I couldn't reproduce it on any of the other testcases/websites other then the amazon website. This testcase is minimized based on that site. I can only reproduce the bug, when I use the windowsXP theme. This regressed between 2007-02-06 and 2007-02-07, which makes it a regression from bug 177805 (the units bug).
Oh, heh, the regression range was already found out.
Keywords: regression
Assignee: nobody → sharparrow1
This appears fixed, as of today's build. Eli, which patch fixed this, do you think?
Bug 382458, likely.
I dont know what you guys did, but it is fixed as of build 2007062711. No funny business noticed on the three sites I tested originally. Thanks.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Verified FIXED with the testcases in comment 22, comment 0, and my own, in the URL, with: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a6pre) Gecko/20070630 Minefield/3.0a6pre
Status: RESOLVED → VERIFIED
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: