21477 - Bookmarks menu unusable due to repeated resize, reloc, redraw

Status: VERIFIED FIXED

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

Description

[Peter Trudelle]

I have a large bookmarks file, with >100 bookmarks at the top level, and many
folders that also have lots of bookmarks.
Using today's opt comm bits on RH 6.0, P166:
Click on Bookmarks menu (not the one in toolbar).
Wait about a minute or so for it to resize and redraw itself endlessly.
When it finally pops up, try to mouse over a folder that contains a lot of
bookmarks.
* A grey rect is drawn where the submenu should be, the size of one menu item.
* Then the parent menu shifts vertically by one item, and back.
* Then the grey rect for the submenu is drawn with two items.
These dance steps are repeated many times as the menu slowly tangoes its way
down the screen.  The whole process takes a bit longer than it is taking me to
type this bug report.
If the menu has to grow to accomodate a longer menu item, or if it hits the
bottom and starts relocating itself back up the screeen (or both!), the effect
would be quite comical, if you didn't have equity in the company expecting to
ship this product.
I could not tell if the menu actually worked, since my RSI had kicked in by the
time the menu finished drawing.

Comment 1

[Chris Waterson]

hyatt thinks i'm sending the frame construction code too many notifications.

Comment 2

[leger]

Putting on PDT- radar.  You can still use Sidebar.

Comment 3

[Chris Waterson]

rjc: i am going to attach a mongo fix for this. i added an |nsIContent**
aFirstGeneratedChild| parameter to several of the methods, which, if non-null,
receives the first content node that is generated from template construction. We
then use this in |OpenContainer()| and |RebuildContainer()| to figure out where
to tell layout to start appending content. This allows us to avoid "noisy"
content creation where we notify layout for each new content node that is
created (and e.g. causes menus to "unfurl"). Can you review?

Comment 4

[Chris Waterson]

Attachment: proposed fix

Comment 5

[Robert John Churchill]

Chris, can you attach a copy of your nsRDFGenericBuilder.cpp file?

"patch" (on both Unix and Windows) seems to have several problems applying
your diff (for me, anyway). <sigh>

Comment 6

[Chris Waterson]

Attachment: patched nsRDFGenericBuilder.cpp

Comment 7

[Robert John Churchill]

(Sorry for the delay.)  This looks good to me, Chris.

Comment 8

[Chris Waterson]

fix checked in, r=rjc

Comment 9

[Claudius Gayle]

hey trudelle, i know your busy but I wouldn't feel right if I didn't allow you the chance to verify this.

Now that I look at it on my p133 linux box though, I'm not convinced it's fixed. Granted my machine
allows me the benefit of slow-mo but based on my reading of waterson's description of his patch I thought
a submenu would get the size right first before it populated itself. I still see the 'unfurling' behavior.

Comment 10

[Chris Waterson]

you might see "two" unfurls, but not an unbounded number, as before.

unfortunately, that's as good as it's gonna get for now.

Comment 11

[Claudius Gayle]

I see what's going on. Restart your browser.
The FIRST time you access the bookmarks menu and submenus,
we see the glorious unfurling that scales with the size of your bookmarks.
Every subsequent access results in the menus being displayed hella fast.
So where does that leave us?

Comment 12

[Peter Trudelle]

I now have a PII-500 running RH 6.1, but this is still completely unusable,
although the show is not as long,  nor nearly as entertaining. reopening.

Comment 13

[Chris Waterson]

ok, gimme your bookmarks file. out of curiosity, do you notice a difference
between the personal toolbar's "bookmarks" menu and the main menu bar's menu?
Do you notice a difference between the first and second times you drop the main
menu?

Comment 14

[Peter Trudelle]

Attachment: bookmarks file

Comment 15

[Peter Trudelle]

Okay, I attached it to this bug.  Other than placement and style, I don't see
much difference between the menus.  The main menu does come up fast after the
first time, but when I try to select from it, the submenus start to dance and I
can't use it at all.

Comment 16

[Peter Trudelle]

*** Bug 22627 has been marked as a duplicate of this bug. ***

Comment 17

[Chris Waterson]

*** Bug 22155 has been marked as a duplicate of this bug. ***

Comment 18

[Claudius Gayle]

*** Bug 24632 has been marked as a duplicate of this bug. ***

Comment 19

[Peter Trudelle]

reluctantly moving from dogfood radar to beta1 radar

Comment 20

[Chris Waterson]

pink: this has now become a positioning problem. when you open the menu code, it

causes the menu to reposition wildly. some kind of evil feedback loop where the

mouseover is triggering the menu to reflow which is triggering the menu to move

which is triggering another mouseover ad infinitum. hyatt recommended you as the

man for the job.

Comment 21

[leger]

Putting on the pdt+ radar for beta1.

Comment 22

[Mike Pinkerton (not reading bugmail)]

*** Bug 25717 has been marked as a duplicate of this bug. ***

Comment 23

[Mike Pinkerton (not reading bugmail)]

fixed.

Comment 24

[Claudius Gayle]

while there are still problems i believe this specific behavior has been dealt with. marking VERIFIED. trudelle, pls reopen if you do 
not concur.