99443 - First line of bookmarks located in column head [@ nsContainerBox::RemoveAfter]

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P1)

Description

[Gilles Durys]

2001091221 trunk linux

Look at the bookmark sidebar and bookmark manage window.
First line of bookmarks is located where the column's title should be.

Comment 1

[Gilles Durys]

Attachment: Screenshot of bookmark sidebar

Comment 2

[R.K.Aa.]

did you try to scroll there? The header gets glued all over.
A resize of pane will refresh.

Comment 3

[R.K.Aa.]

similar bug in the "Address Book" tab

Comment 4

[Gilles Durys]

Yep scrolling the bookmark has the same effect.
The address book is pretty screwed up too.

Comment 5

[R.K.Aa.]

upping severity... this smells like a "mostfreq-to-be"
CC waterson in case he has an idea what caused this.. please remove yourself if
i guess wrong.

Comment 6

[R.K.Aa.]

More fun: resizing AB pane causes a crash.

Comment 7

[R.K.Aa.]

Attachment: backtrace

Comment 8

[R.K.Aa.]

to repro: drag horizontal divider down, then up: crash
TB35326480X
TB35326543H

Comment 9

[Kathleen :Brade]

Here is first talkback id's trace:

operator []() 
nsCOMPtr_base::assign_from_helper() 
nsEventListenerManager::RemoveEventListener() 
nsEventListenerManager::RemoveEventListenerByType() 
nsXULElement::RemoveEventListener() 
nsXULTreeGroupFrame::~nsXULTreeGroupFrame() 
nsFrame::Destroy() 
nsContainerFrame::Destroy() 
nsBoxFrame::Destroy() 
nsFrameList::DestroyFrame() 
nsXULTreeGroupFrame::ContinueReflow() 
nsTreeLayout::LazyRowCreator() 
nsXULTreeOuterGroupFrame::ReflowFinished() 
PresShell::HandlePostedReflowCallbacks() 
PresShell::ProcessReflowCommands() 
PresShell::FlushPendingNotifications() 
nsSplitterFrameInner::AdjustChildren() 
nsSplitterFrameInner::MouseDrag() 
nsSplitterFrame::HandleEvent() 
PresShell::HandleEventInternal() 
PresShell::HandleEvent() 
nsView::HandleEvent() 
nsViewManager::DispatchEvent() 
HandleEvent() 
nsWidget::DispatchEvent() 
nsWidget::DispatchWindowEvent() 
nsWidget::DispatchMouseEvent() 
nsWidget::OnMotionNotifySignal() 
nsWindow::HandleGDKEvent() 
dispatch_superwin_event() 
handle_gdk_event() 
libgdk-1.2.so.0 + 0x1716b (0x4033d16b) 
libglib-1.2.so.0 + 0x10055 (0x4036d055) 
libglib-1.2.so.0 + 0x10659 (0x4036d659) 
libglib-1.2.so.0 + 0x107e8 (0x4036d7e8) 
libgtk-1.2.so.0 + 0x9165b (0x4028265b) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x1c177 (0x404ae177) 

Comment 10

[Chris Waterson]

I'll take a first look at this one; may be related to checkin from bug 84645.

Comment 11

[Chris Waterson]

Attachment: minimized test case

Comment 12

[Chris Waterson]

This must be related to my change, but I'm still tracking it down. The problem
appears to be related to the way that the XUL sort service removes, then
appends, content after doing sort.

Comment 13

[Chris Waterson]

Okay, I botched the logic when porting from nsFrameManager::AppendFrames().
Patch coming up.

Comment 14

[Chris Waterson]

Attachment: Use the first appended content to find the filtered insertion point, if one exists.

Comment 15

[Chris Waterson]

So this patch still isn't quite right, but it is compatible with what we were
doing before. Ideally, we'd do what the XXX comment says. I think hyatt filed a
bug on that somewhere.

Comment 16

[R.K.Aa.]

tested the patch (linux): no more crash and all looks nice again.

Comment 17

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

Comment on attachment 49253 [details] [diff] [review]
Use the first appended content to find the filtered insertion point, if one exists.

r=dbaron if you get sr from hyatt

Comment 18

[David Hyatt]

It would take about 10-15 minutes to fix this the right way.  You can call
GetSingleInsertionPoint to get the unfiltered point and to find out if multiple
points exist.  If multiplePoints is false, then you can use the adjusted parent
from GetSingleInsertionPoint.  If multiplePoints is true, then you can walk each
child, and make individual ContentInserted calls.

Anyway, sr=hyatt for the hack, but you'll get extra hugs and kisses from me if
you fix it the right way. ;)

Comment 19

[Chris Waterson]

I'm not sure it's that simple. If it _is_ that simple, then why must
nsCSSFrameConstructor::GetInsertionPoint() recur? Anyway, I'll check in the
above patch, open a new bug to fix the problem the right way, and attach a patch.

Comment 20

[Chris Waterson]

Fix checked in. Opened bug 99543 to fix ContentAppended() the right way.

Comment 21

[Chris Waterson]

Linking to topcrash that should be fixed...

Comment 22

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]