Closed Bug 79732 Opened 23 years ago Closed 5 years ago

The letters "j" "y" and others leaves pixels on screen

Categories

(Core :: Layout: Text and Fonts, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(12 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001050904

If you have a DIV containing the letter "j" and drag the DIV to the right It 
will "leave" pixels on the screen. Like dirt.

Reproducible: Always
Steps to Reproduce:
1. running the code gives the error every time
2.
3.

Try this. Drag the red box to the right slowly and you will see the bug.

<HTML>
<HEAD>
<TITLE></TITLE>
<SCRIPT LANGUAGE="JavaScript">
<!--
var selectedObj = false, offsetX, offsetY;

document.onmousemove = mouseMove;
document.onmouseup = mouseUp;
document.onmousedown = mouseDown;

function mouseDown(e){
	if(e.target.id.indexOf("drag") != -1){
		selectedObj = document.getElementById(e.target.id).style;
		offsetX = e.layerX;
		offsetY = e.layerY;
	}
}	

function mouseMove(e){
	if(selectedObj != false){
		selectedObj.left = e.clientX - offsetX;
		selectedObj.top = e.clientY - offsetY;
		return false;
	}
}

function mouseUp(){
	selectedObj = false;
}
//-->
</SCRIPT>
</HEAD>

<BODY SCROLL="no">
<DIV ID="drag1Div" STYLE="position:absolute; left:350; top:100; width:100; 
height:50; background-color:red; cursor:move;">j</DIV>

</BODY>
</HTML>
updating component
Assignee: asa → blakeross
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: Drag and Drop
Ever confirmed: true
QA Contact: doronr → tpreston
Wow, what a cool bug.  Some painting/layout issue (the tip of the j is outside 
of the div, which is apparently causing this).

Cc'ing roc and attinasi, --> karnaze
Assignee: blakeross → karnaze
The mathml's GetBoundingMetrics function gives more precise metrics 
(specifically, the leftBearing here), but that will be overkill as it is 
expensive and could change the CSS layout model if used improperly :-)

Or to proceed as IE. The way it seems to work in IE is because they clip the 
rendering to the containing block. But clipping _without_ overflow=clip is a
bug, right?

The problem is more acute by taking a large italicized 'j'.
Adding a dependency with bug 96041 because it boils down to the same issue.
Depends on: 96041
Keywords: 4xp
-->attinasi
Assignee: karnaze → attinasi
Taking this bug
Assignee: attinasi → kmcclusk
Target Milestone: --- → mozilla1.1
Bulk moving Mozilla1.1 bugs to future-P2. I will pull from this list when
scheduling post Mozilla1.0 work.
Priority: -- → P2
Target Milestone: mozilla1.1 → Future
This WFM on both XP and 2000 using new builds.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
reopening, the bug is still there, you won't see it if your default font doesn't 
cause the 'j' to stick outside. (You can set a large font-size on the <style> 
element in the testcase to make the bug more apparent.)
Attached file Now with bigger font (obsolete) —
I changed the testcase so you now have a bigger J and I still cant reproduce
this bug. This was very visible before even with the default font.

What build are you using? Or am I missing something.
Weird, now this WFM again using build 20020603 on Windows 2000. Can anybody else
confirm?
I see this on Win XP trunk build 2002060408
Keywords: mozilla1.1, testcase
OS: Windows 2000 → All
Hardware: PC → All
Now this works for me (yeah, i know, again) on Windows 2000, XP and Mac OS 9. 
Can anybody confirm?
Marking WFM, after not being able to reproduce on Windows 98/2000/XP and Mac OS 9.
Status: REOPENED → RESOLVED
Closed: 22 years ago22 years ago
Resolution: --- → WORKSFORME
Again I am seing this... This seems to disappear and reappear from time to time.
Build 2003042708, Windows 2000.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Keywords: mozilla1.1
Keywords: regression
Not a regression. It has never been fixed as I said many times.
Keywords: regression
Well, it worked fine in Mozilla 1.3.1 Windows 2000.
> screenshot - today's tip of the tree - 28 March 2002

Wow, that was definitely a buggy tip -- it submitted many times...
Assignee: kmcclusk → blake
Status: REOPENED → NEW
QA Contact: tpreston → pmac
The testcases don't work with IE6.
Both IE and Opera cuts off the j.
Attachment #58541 - Attachment is obsolete: true
Attachment #76537 - Attachment is obsolete: true
*** Bug 15116 has been marked as a duplicate of this bug. ***
Blocks: 280822
*** Bug 308388 has been marked as a duplicate of this bug. ***
*** Bug 348370 has been marked as a duplicate of this bug. ***
Assignee: bross2 → nobody
Component: Drag and Drop → Layout: Fonts and Text
QA Contact: pmac → layout.fonts-and-text
Summary: Dragging stuff containing the letter "j" leaves pixels on screen → The letters "j" "y" and others leaves pixels on screen
Works for me with build 2007092405
I think it was fixed with bug 96041
(In reply to comment #35)
> Works for me with build 2007092405
> I think it was fixed with bug 96041
> 

This is still broken for me using trunk build Gecko/2007092504 on Windows 2000
Yeah, this isn't really fixed because we don't compute overflow areas for all text, just text that is in high-quality-mode.
Using build 2007121605 on Windows 2000:

I don't see any pixels left on the screen anymore when dragging the div around.
Should this bug be marked as WFM or FIXED now that there are no pixels left on screen when dragging the div in the testcase around?
Attachment #58541 - Attachment is obsolete: false
Never mind, attachment 58541 [details] still shows this.
Reproduced using testcase in attachment 58541 [details]:
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1
WFM -> attachment 161128 [details]
Confirmed (bug not fixed) -> attachment 58541 [details]

Using Nightly 11
WFM with latest trunk on OS X 10.9.1. Can someone confirm this on Windows as well? To confirm this, try out the attachments on this bug and attachment 58541 [details].
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

AFAICS, this is no longer an issue in current versions (and has been fixed for quite a while); closing as WFM.

Status: NEW → RESOLVED
Closed: 22 years ago5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: