Status

()

defect
RESOLVED FIXED
14 years ago
11 months ago

People

(Reporter: tristan, Assigned: roc)

Tracking

({qawanted, testcase})

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

The current opening page at maihem.org (and also just about any page with
similar layout) shows text correctly until you mouseover and cause the
overlapping elements to be displayed.

The menu in the example page is implemented as a one row table containing
various unordered, and definition lists - using dl:hover>dd to cause submenus to
appear. When a submenu appears, the text below the menu is shifted by one pixel
in the rectangle from the left to the right of the menubar <table>, from the top
to the bottom of the individual submenu dd element.

This shifts back when the menu is undisplayed.

I have not reported this under "Trivial" but rather "Normal" as it is a problem
rendering webpages that has no workaround.

Reproducible: Always

Steps to Reproduce:
1. Visit maihem.org
2. hover over a menu, watch the text below the menubar move as far down as the
end of the submenu
3. watch in astonishment as the text moves back where it should be when you move
the mouse away from the menus
4. Also note how slowly the menus are displayed... This is only css :hover magic.

Actual Results:  
I reported this bug :)

Expected Results:  
The text in the rectangle marked bey the horizontal extent of the menu's table
element and the vertical extent of the popup submenu's dd element should have
remained steady as a rock, and the menu should have popped up much faster.
> Actual Results:  
> I reported this bug :)

That was funnier in the form (where it said something like: "What happened
afterwards") :)

I didn't have any other information to put in that section.
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Need minimal testcase....
Keywords: qawanted
I suspect the page has changed. I can't find a menu to mouseover on.
Tristan, is there a site/url were we still can see the issue?
I didn't realise I broke the page, this should be working again now. Note that the menu is produced by xsl and looks like:

<table><tr><td><dl><dt>menutitle1</dt>
                   <dd><ul><li>item1</li>
                           <li>item2</li>
                           <li><dl><dt>menutitle2</dt>
                                   <dd><ul><li>item3</li>
                                       </ul></dd></dl></li>
                           </ul></dd></dl></td></tr></table>
This is WFM using 1.5 and latest trunk build on Windows XP. Maybe Linux only?
Yes, this is WFM for me also on trunk build, windows.
Tristan, maybe you could attach a minimal testcase yourself?
Yes, It certainly is Linux only. I've seen it on i386 1.0.7 on i386 kernel, on AMD64 kernel, and I've seen it with i386 1.5 on AMD64 kernel. I've also seen it on Ubuntu Linux's unofficial AMD64 builds of 1.0.7 and 1.5 on AMD64 kernel.

I will make a minimal testcase right away.
Posted file Testcase
mouseover menuitem1, and some text appears below it over the top of the paragraphs, the paragraphs move behind the overlayed menu. mouse over menuitem2, and some more of the paragraph text moves.

There is a line of css in the file that is commented to point out that different point sizes hide or display this effect. So it may be possible to make this happen on Windows.
Thanks for the testcase, Tristan.
With the testcase, I can see the bug too (but only slighly).
This seems similar to bug 293638.
This doesn't look like the same thing as in bug 293638. I see my testcase clearly moving the behind text up by a pixel in the rectangle from the leftmost extent of the :onhover displayed text to the rightmost extend, and from the topmost extend of the :onhover displayed text to the bottommost. It is as if the overlayed text is drawn by grabbing the behind text, drawing over it, then blitting it all back in one go - one pixel too high.

It looks like it could be a rounding difference converting the logical points to screen pixels between two compositing stages. I've also seen rounding differences in other places when using points (getting unexpected gaps and things like that). Perhaps this is part of a more general problem than simply a text jiggle?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051227 Firefox/1.6a1

Works for me.
Keywords: testcase
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: Layout → Layout: View Rendering
Depends on: 293638
Ever confirmed: true
QA Contact: layout → ian
Not entirely sure (since I hardly can see the bug anyway), but I think this is WFM in my debug build that has the "frame display lists" patch in it (bug 317375).
Depends on: 317375
Yeah, eliminating widgets for position:fixed will make this happier.
Yes, definetely fixed by bug 317375, can see the bug in a 2006-01-18 build, but can't see it anymore in a 2006-01-27 1:19am tinderbox build.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.