38233 - menus trigger excessive RDF content construction

Status: RESOLVED FIXED

(Core :: XUL, defect, P2)

Description

[Chris Waterson]

rjc and I were looking at bug 29359 (which deals with loading search.dll at
startup), and it turns out that this is not the real problem.

The real problem is that XBL and menu frame construction code is very aggressive
about probing the content tree for children. This forces RDF to "fault" and
generate content (triggering e.g., search queries to run) at inopportune times.

This broke a while ago when I removed special-case menu code that paid attention
to the "open" attribute on <menu> tags. I can't remember the bug number, but
this used to cause the "unrolling" menus.

we need to figure out a better mechanism here, it is affecting startup
performance on mac, and XP menu performance across the board (e.g., unrolling
the "bookmarks" menu causes *all* submenus of that menu to be pre-generated,
rather than waiting for a mouseover).

Comment 1

[Robert John Churchill]

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

Comment 2

[Chris Waterson]

taking from pink per our discussion yesterday. will try to revive use of "open"
attribute and lying about children.

Comment 3

[John Morrison]

The duplicate bug #37118 was nsbeta2+. Adding nsbeta2 for consideration of pdt

Comment 4

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 5

[karnaze (gone)]

Waterson says the crash has been fixed. Removing crash keyword and changing from 
nsbeta2+ to nsbeta2-. 

Comment 6

[Chris Waterson]

Attachment: fix: don't build content if container contents haven't been generated yet.

Comment 7

[Robert John Churchill]

Chris, I applied your patch on my Mac build. I'm still see things like "IE 
Favorites" read in on startup (based upon timing output in the console 
window).  :(

Comment 8

[Chris Waterson]

Right, I think that we need to fix 46108 first.

Comment 9

[Robert John Churchill]

For yucks, I modified CheckContainer() in the XUL template builder to never 
compute "empty" [i.e. never call GetTarget()] and the problem still exists... so 
some code somewhere else is still being overly aggressive.

I also noticed that if I run mozilla and do a search from the search sidebar 
panel, as soon as I click on the panel's "Search" button, I see several "find:" 
URLs being executed in the console as well.  (That's with the "empty" computation 
disabled.) Probably the same problem.  [Its a good test though, as it happens on 
all platforms, unless the "IE Favorites" being read at startup problem, which is 
Mac only.]

Comment 10

[Robert John Churchill]

[On the Mac] Setting a breakpoint at "nsBookmarksService.cpp::ReadFavorites()" 

and then looking up the stack reveals that what's causing the excessive content 

construction is "nsXULDocument::ResolveForwardReferences()"

Comment 11

[Chris Waterson]

hyatt checked in the fix for this.