278353 - Position:fixed breaks for xhtml file

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Pete Harlow]

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.

Comment 1

[Pete Harlow]

Attachment: Test Case

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.

Comment 2

[Pete Harlow]

Attachment: 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.

Comment 3

[Anne (:annevk)]

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?

Comment 4

[Pete Harlow]

Attachment: 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?

Comment 5

[Pete Harlow]

Attachment: Screen shot of bug 278353

Screen shot of the bug occuring scrolling up the page with the mouse wheel.

Comment 6

[Pete Harlow]

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.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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...

Comment 8

[Boris Zbarsky [:bzbarsky]]

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...

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not seeing this in a GTK2 build. Is it GTK1 only?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Looks like it might be, yes.  I'm seeing it in a GTK1 build but not GTK2 build
built from the same tree.

Comment 11

[Pete Harlow]

I can see the problem in both the GTK1 and GTK2 builds of 1.8a6.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'll make a GTK1 build and see if I can reproduce.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The GTK widget is not being shown properly. We think it's showing, but it really
isn't.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

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...

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It looks like this is causing Luna to crash during DHTML performance tests. But
not any other tinderboxes.

Hmm.

Comment 17

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Very few run the Tdhtml tests.

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

True.

Backed out.

Comment 19

[[e-mail]]

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.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Neil, can you still reproduce the crash in a GTK1 build of your own, with this
patch?

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Luna went green. I think either we were seeing some transient problem before, or
some problem which has since been fixed elsewhere.