User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1 Googles image search displays the selected image in a horizontal frame at the top of the page, and the page on which it was found in a second frame. Page also includes a "remove frames" command. In a single window, "remove frames" works as expected. In a tab, frames appear to be removed but upon scrolling or reloading, the window acts as if the frame is still there. Reproducible: Always Steps to Reproduce: 1.open http://www.google.com/imghp?hl=en&tab=wi&q= 2.search on a topic (I use 914-6) 3.right click at least one picture and open in new tab 4.click "remove frame" at top right (page reloads without frame) 5.click anywhere on the "frameless" tab 6.scroll Actual Results: Only part of the page scrolls (scrolling happens within area of supposedly-removed frames) Expected Results: entire page should scroll. if rightclick then "open in new window" instead of "open in new tab", frame removal and scrolling work as expected. This happens on both my DeerPark builds and tqh's latest as posted on Bebits.

This problem does not occur on Windows nightly build of 1.6a1. Attached file is terminal output of debug build while problem happens. StyledEdit document. Red text are my comments, trying to put some context around what happens when the problem occurs. Also discovered if, once the frame reappears, clicking on frame as if to move it causes it to disappear and the tab window behaves normally thereafter.

text formatting lost in upload but the notes are pretty obvious. Anyone have any ideas?

duplicated again tonight with a clean build from CVS - same issue. Anyone?

Apparently related to changes introduced in bug 274784. Problem does not happen when browser.sessionhistory.max_viewers is set to 0.

set blocking 274784 as requested in https://bugzilla.mozilla.org/show_bug.cgi?id=274784#c151

This is looks like symptopm of more ugly bug. E.g. i cannot sometimes perform even step 3. Pages get "blocked" or nonactivated totally, especially if address is used before, so content updated, like submitting posting in forum, but address remains the same. Also there is some blinking of older content over new, wrong scrollbar placement etc etc. Maybe we shoudl change also Summary of this bug

confirmed Sergei's observations. Changed description accordingly.

latest CVS sets browser.sessionhistory.max_views=-1 by default, effectively disabling fbcache. I suspect this bug may be a duplicate of some other.

WORKSFORME in SeaMononkey 2005-10-04-5-trunk

re: WORKSFORME. Please use about:config to confirm browser.sessionhistory.max_viewers is > 0 and retest. Latest trunk sets this value to -1 by default. That would give the appearance of working but really just disables the code that has the problem.

good news: initial testing of build with both fyysik's 315542 scroll fix v2 plus 315576 nsAppShell priority fix does not display this problem. more testing to follow, but this is progress!

setting sessionhistory.max_viewers value to 10 in SeaMonkey renders it to absolutely unusable product. Nothing works, even about:config don't load, so you cannot set parameter back, without restarting browser

Sounds like a BeOS widgetry issue to me...

Hmm, we should look into if that 'weird' nsWindow::destroy code could be involved. Sergei, have you looked into that yet? And maybe we should investigate exactly what views/windows relations are maybe use the scripting capabilities of BeOS (hey pherhaps) to find out more. In fact a tool to investigate BView/BWindow and also nsWindow relations could probably help debugging a lot.

Changing to "worksforme". Changes elsewhere related to fastback/fast forward seem to have cleared up the specific issue reported here. Some issues with repainting remain (for instance, links don't always show up as clickable until a the back/forward buttons are pressed) but seem to be reflective of greater issues. This BeOS specific bug can be closed.