Closed Bug 278353 Opened 17 years ago Closed 17 years ago

Position:fixed breaks for xhtml file

Categories

(Core :: Web Painting, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: peter.harlow, Assigned: roc)

References

()

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

To reproduce:
Load URL or xhtml page in test case into reduced size browser window.
Note menu using style position:fixed in top right hand corner.
Scroll down - menu disappears - it should remain fixed to viewport.
Move mouse over area where menu was - :hovers are still active.
Scroll up - menu splatters over scrolled area.

Now load html test case - page behaves correctly.

This bug seems dependent on the mime type for served pages  - the mime header
for the quoted url is:
Content-Type: application/xhtml+xml; charset=ISO-8859-15
wheras a very similar menu on the page:
http://www.w3.org/Style/Examples/007/menus.html
served as:
Content-Type: text/html; charset=iso-8859-1
behaves normally.

For local pages the bug seems dependent on the file extension - the bug is seen
on pages with the extension xhtml but the same page (which in the test case is a
valid xhtml1.1 document) with the extension html is rendered correctly.

This bug is not seen with Mozilla 1.7.5 or derivatives such as Firefox.

It is seen under 1.8a5 with and without the bug 268111 patch.

With later builds (either a6 or the latest nightly - I'll confirm later)
the bug is still present when the page loads, but changing the window size fixes
it temporarily.
Attached file Test Case (obsolete) —
This test case contains two valid xhtml 1.1 documents, index.php.xhtml and
index.php.html which are identical apart from the file extension. The bug only
appears when index.php.xhtml is loaded.
Attached file Test Case
The original test case was corrupted when saved and thrown out by 1.8a6 xml
parser. This should be OK. The bug appears in exactly the same form with a6 -
it must have been the latest nightly that recovered on the window resize.
Attachment #171244 - Attachment is obsolete: true
This works for me. Could you perhaps attach a testcase that has everything
inside a single file? And uses the minimal needed markup and style to reproduce
the problem?
Attached file Test page
Here is the page with the cruft cut out and the formatting tidied up. To follow
a screen shot of how it corrupts on scrolling. Anne - what platform are you
using? This bug could be dependent on how the filesystem is reporting the file
type?
Screen shot of the bug occuring scrolling up the page with the mouse wheel.
This bug appears to be platform dependent. There is no sign of it under Windows
2000 with either local or served files.
I've seen the bug so far under SuSE Linux 7.3, Fedora Core 1 and Yellow Dog 3.1
for PPC.

Note saving the opened file corrupts it - shift clicking the link above saves
the file correctly.
Hmm..  This seems to have broken when widget change caching landed, based on
testing in nightlys.  If I remove the 

    if (!mViewManager->IsRefreshEnabled()) {
      return;
    }

in nsView::ResetWidgetBounds, then the bug disappears.  I'm not sure why it's
only an issue in XHTML...
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b?
Keywords: regression
Note that there are no calls into nsView::ResetWidgetBounds while scrolling, so
it's looking likely that the problem creeps in during document setup (while
refresh is disabled by the content viewer) or something...
Flags: blocking1.8b? → blocking1.8b+
I'm not seeing this in a GTK2 build. Is it GTK1 only?
Looks like it might be, yes.  I'm seeing it in a GTK1 build but not GTK2 build
built from the same tree.
I can see the problem in both the GTK1 and GTK2 builds of 1.8a6.
I'll make a GTK1 build and see if I can reproduce.
The GTK widget is not being shown properly. We think it's showing, but it really
isn't.
Attached patch fixSplinter Review
The problem is that showing a widget moves it to the front of the z-order, and
resizing a widget can cause it to be shown (when it was too small before), and
we have changed the order in which widgets are resized. So we ended up moving
the viewport's scrollport widget above the widget for the fixed element, but
our code assumes that the widgets for fixed elements are above the scrollport
(otherwise those widgets are useless).

First I factored the code so that the show/hide logic in Resize was entirely
subsumed by the same logic in ResetInternalVisibility. It would have been nice
if we could just call gdk_window_show_unraised but that doesn't exist in GTK1.
So I ported the GTK2 widget z-ordering code from bug 261238 to GTK1 and I call
it after calling gdk_show_window, to put the windows back in the right z-order.


This patch should have the effect of fixing bug 261238 for GTK1. I can't test
it right now because I don't have a 64-bit libflashplayer.so...
Attachment #174337 - Flags: superreview?(blizzard)
Attachment #174337 - Flags: review?(blizzard)
Attachment #174337 - Flags: superreview?(blizzard)
Attachment #174337 - Flags: superreview+
Attachment #174337 - Flags: review?(blizzard)
Attachment #174337 - Flags: review+
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
It looks like this is causing Luna to crash during DHTML performance tests. But
not any other tinderboxes.

Hmm.
Very few run the Tdhtml tests.
http://mozilla.org/performace/test-cases/dhtml/meter/index.html appears to be
the loaded page, but I'm not sure, because I never seemed to see any end
document loads and the throbber was still spinning, so I'm basing it on the last
document with a JavaScript strict warning.
The first time mozilla segfaulted in main_arena from libc, called from unknown,
called from g_idle_dispatch, called from g_main_dispatch, called from
g_main_iterate, called from g_main_run in libglib, called from gtk_main in
libgtk, called from nsAppShell::Run, called from nsAppStartup::Run, called from
main1, called from main, called from __libc_start_main.
The second time it crashed in nsWindow::UpdateIdle because &(window->Update) was
null.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I reran the DHTML tests with my patch and I don't crash. I do --- on both GTK1
and GTK2 --- get assertions about ReflowDirtyLines failing just before the meter
test. I'll try to track that down.
In that case reflow is failing in nsTextFrame because we don't have a document.
This is a reflow generated by the call to SetTextZoom from
nsDocShell::SetupNewViewer (setting up the content viewer for testcase
layers5.html). Since it's reflowing the new document viewer, I don't see how the
document can be gone. Perhaps we finished the test before SetupNewViewer ran,
and unloaded the document somehow?
Neil, can you still reproduce the crash in a GTK1 build of your own, with this
patch?
I just got biesi to try it and he can't reproduce the crash either.

I think we should just reland and see if luna goes orange again. If it does, we
can back out right away. If it doesn't, something changed in the meantime that
fixes the crash.
Comment on attachment 174337 [details] [diff] [review]
fix

This patch fixes a layout issue in GTK1 builds. When we last tried to land it,
it triggered in crash in DHTML performance tests. But neither I nor biesi can
reproduce the crash. I want to reland this to see if the crash is still there
on luna. If it is, we can back out right away.
Attachment #174337 - Flags: approval1.8b2?
Attachment #174337 - Flags: approval1.8b2? → approval1.8b2+
Luna went green. I think either we were seeing some transient problem before, or
some problem which has since been fixed elsewhere.
Status: REOPENED → RESOLVED
Closed: 17 years ago17 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.