Closed
Bug 278353
Opened 20 years ago
Closed 19 years ago
Position:fixed breaks for xhtml file
Categories
(Core :: Web Painting, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: peter.harlow, Assigned: roc)
References
()
Details
(Keywords: regression)
Attachments
(4 files, 1 obsolete file)
17.28 KB,
application/x-gzip
|
Details | |
2.46 KB,
application/xhtml+xml
|
Details | |
33.53 KB,
image/png
|
Details | |
14.63 KB,
patch
|
blizzard
:
review+
blizzard
:
superreview+
dbaron
:
approval1.8b2+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
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.
Reporter | ||
Comment 2•20 years ago
|
||
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
Comment 3•20 years ago
|
||
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?
Reporter | ||
Comment 4•20 years ago
|
||
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?
Reporter | ||
Comment 5•20 years ago
|
||
Screen shot of the bug occuring scrolling up the page with the mouse wheel.
Reporter | ||
Comment 6•20 years ago
|
||
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•20 years ago
|
||
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
Comment 8•20 years ago
|
||
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...
Updated•20 years ago
|
Flags: blocking1.8b? → blocking1.8b+
Assignee | ||
Comment 9•20 years ago
|
||
I'm not seeing this in a GTK2 build. Is it GTK1 only?
Comment 10•20 years ago
|
||
Looks like it might be, yes. I'm seeing it in a GTK1 build but not GTK2 build built from the same tree.
Reporter | ||
Comment 11•20 years ago
|
||
I can see the problem in both the GTK1 and GTK2 builds of 1.8a6.
Assignee | ||
Comment 12•20 years ago
|
||
I'll make a GTK1 build and see if I can reproduce.
Assignee | ||
Comment 13•20 years ago
|
||
The GTK widget is not being shown properly. We think it's showing, but it really isn't.
Assignee | ||
Comment 14•20 years ago
|
||
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)
Updated•20 years ago
|
Attachment #174337 -
Flags: superreview?(blizzard)
Attachment #174337 -
Flags: superreview+
Attachment #174337 -
Flags: review?(blizzard)
Attachment #174337 -
Flags: review+
Assignee | ||
Comment 15•20 years ago
|
||
checked in
Assignee | ||
Updated•20 years ago
|
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•20 years ago
|
||
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.
Assignee | ||
Comment 18•20 years ago
|
||
True. Backed out.
Comment 19•20 years ago
|
||
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.
Assignee | ||
Updated•20 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 20•19 years ago
|
||
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.
Assignee | ||
Comment 21•19 years ago
|
||
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?
Assignee | ||
Comment 22•19 years ago
|
||
Neil, can you still reproduce the crash in a GTK1 build of your own, with this patch?
Assignee | ||
Comment 23•19 years ago
|
||
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.
Assignee | ||
Comment 24•19 years ago
|
||
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+
Assignee | ||
Comment 25•19 years ago
|
||
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: 20 years ago → 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•