Closed Bug 112673 Opened 23 years ago Closed 22 years ago

Text gets partially offset when scrolling

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 80530
Milestone:
mozilla1.2alpha

People

(Reporter: bryner, Assigned: attinasi)

References

Details

Attachments

(1 file)

screen shot of problem
64.01 KB, image/png
Details 
Sometimes when a line of text is only partially in view, and you then scroll so
that the entire line is visible, the bottom part of the line of text ends up
shifted one pixel to the right relative to the top part, creating an unintended
"italics" effect.

In the screen shot I'm about to attach, look at the line "in it's 8th printing,
so it's been doing well.", at the end of the second article that's visible.
Attached image screen shot of problem — 

    
    

    
  
Sounds kinda like bug 16200 and unrelated to the font code.

    
    

    
  
Er, actually, that wouldn't explain it since you didn't scroll horizontally.

    
    

    
  
-> ftang
Assignee: bstell → ftang

    
    

    
  
I've seen this too. Look at the "posted by", where only part of the text is offset.

Scrolling vertically doesn't fix this, but selecting thte text, opening/closing
a context menu above the text, and so on, does fix this.

I saw this since I upgraded to RH7.2. I don't tihnk this is a font problem,
since it fixes itsself on a repaint. IT could be an X problem, I guess. bryner
and I both have different video cards, though.

    
    

    
  
is this different than bug 87738?

    
    

    
  
I think so... looking at the "xmag of attachment 40047 [details]" on bug 87738, I don't
see the pixel shift.


    
    

    
  
in attachment 40075 [details] the text

    "me dice por co"
The "me di"          is aligned with the bottom of the window.
The      "ce por co" is shifted up one pixel

This an ugly font. Look at the 'e', 'c', and 'r', ugh. If this is outline
scaled fonts I would prefer not to use them.

    
    

    
  
Ok, so my problem shows a shift horizontally, the other shows a vertical shift.


    
  
Status: NEW → ASSIGNED

    
    

    
  
nominating for nsbeta1... this looks pretty bad when it happens.

Keywords: nsbeta1

    
    

    
  
-> shanjian
Assignee: ftang → shanjian
Status: ASSIGNED → NEW

    
    

    
  
I saw this on my window too. (in editor)
It seems a problem with the problem with paint event. I don't think this is a
text drawing problem in GFX. (What will happen to IMAGE if it is placed next to
it ?)
Not sure who should take a look at this. Someone familiar with paint event
should inviegate it. Shanjian probably is not the right person to take this oen.
give it to mcafee
Assignee: shanjian → mcafee

    
    

    
  
resassign to default layout person
Assignee: mcafee → attinasi
Target Milestone: --- → mozilla1.2

    
    

    
  
I see this every day -- use the mousewheel to scroll vertically, and everything
below the point that was on the bottom when the scroll started will be offset by
one pixel horizontally from everything above it.  I've seen it on RH71 and RH72,
on at least three different video cards, with different font setups (both raster
and truetype), and I've never seen anything like this in any other app, so I
doubt that it's an X, system, or X font problem.  I don't see it on every page,
though; it's sensitive to what text is at the bottom when the scroll happens. 
Would it help if I found a reproducible case?

    
    

    
  
yes, a reproducible case would help determine if the issue was in the font
subsystem of the layout layer.

    
    

    
  
*** Bug 124745 has been marked as a duplicate of this bug. ***

    
    

    
  
See also bug 124745, does the scrolling offset explain the
offset when a mozilla window is not on top and then moved to the
top?

    
    

    
  
Perhaps if we draw a box around the text we can tell see if the box is
offset as well as the text.

If the box is partially offset then we should look at the code
that repositions the pixels.

If the box is fine but the glyphs are partly offset then we should
look at the code that draws the glyphs.

Maybe rendering the text a second time in an off screen window and
bringing down the 2 sets of pixels and comparing.


    
    

    
  
It's not just scrolling.  On Friday I saw this happen after a pulldown menu had
covered the upper half of a line.  Unfortunately I haven't found a reproducible
case.

    
    

    
  
I found a non-scrolling case where I'm seeing this reproducibly: in the browser,
do a Find In Page, type in a pattern, keep searching until "not found" dialog
comes up.  In my window manager, the smaller "not found" dialog comes up
centered over the parent "Find" dialog, and is sized so that it obscures the top
half of the Find dialog's buttons.  Now dismiss the "not found" dialog, and
notice that in the Find dialog, the top half of the Find button (both letters
and border) is offset one pixel to the right compared to the lower half.  The
Cancel button is not affected.

    
    

    
  
> notice that ... the top half of the Find button (both letters
> and border) is offset one pixel to the right

Humm, that "and border" speaks to me.

    
    

    
  
Marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
    

    
  
Found another reproducible one.  Go to slashdot.org, and resize your browser so
that a headline (one of the big-white-block-letters-on-green headers) is half
cut off at the bottom of the screen.  Once you have the size right, hit reload
(not sure if this step is required).  Notice that the page displays first
without the boxes down the right side of the page (I don't have any slashdot
cookies; someone with a slashdot account might see a different format) and then
redraws later with the right half of the table.  Once it finally finishes
shuffling things around and redrawing, scroll down with the mousewheel.  The
lower half of the header that was partially displayed will be offset one pixel
to the right.  Scrolling with page down doesn't cause this, only mousewheel
scrolling.

    
    

    
  
*** Bug 126122 has been marked as a duplicate of this bug. ***

    
    

    
  
I mentioned that page up/down scrolling didn't cause this but mouse scrolling
did.  Shortly after I submitted, I discovered that scrolling down with the
spacebar *does* trigger it.  Slashdot turns out to be a good test case.  Click
around in slashdot comments to a story, using spacebar and the mousewheel to do
your scrolling, and you'll see this happen quite often on italicised lines of
comment text.

    
    

    
  
Pav: could this be caused by copying from the off screen buffer?

    
    

    
  
This might be related to the problem I have been experiencing in Mozilla with my
web page @ http://linuxart.com/ (default leaf theme).

When you move the mouse over any link (either text or img), it sometimes will
shift it over and/or down by a pixel. This mostly happens in the middle column
area, and I have not specified anything for it to do this in CSS or in HTML. I'm
using validating XHTML and CSS (well, the CSS transparency hacks for the photos
in Moz and IE do not validate, but everything else does).

When scrolling, I see the same effect once in a while, for what it's worth.


    
    

    
  
(I think bug 133991 is another dup of this).

I am seeing this as well, but on Win98. Changing OS to All.

Another example can be seen at:

http://www.sacbee.com/content/news/story/1987845p-2201460c.html

-- after the page loads, simply 'mouse over' the left-hand floating toolbar.
This should display some floated positioned tool-tip style -- but at the 
same time, portions of adjacent text actually shift slightly to the right 
by one pixel.

Interestingly, this seems problem seems to magically go away if I leave the
browser running for too long ...
OS: Linux → All

    
  
Blocks: 134942

    
    

    
  
Another page where it happens: http://www.linux.org.uk/

Every time I scroll I get broken text, when you select the broken text it is
drawn correctly.


    
    

    
  
db@zigo, please look at bug 120918 and bug 80530, try to change your mozilla
font prefs DPI settings, if it helps (for most people it does).

    
    

    
  
is this a dup of bug 80530?

    
    

    
  
Same web site and very similar screenshot to bug 80530.

Resolving as duplicate. If you think this is not a duplicate, feel free to reopen.

*** This bug has been marked as a duplicate of 80530 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE

    
  
No longer blocks: 134942

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: