49096 - category tree flickers when you open prefs dialog

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[sairuh (rarely reading bugmail)]

this has been around for a week or two... asa/rkaa/blake, could you let us know
if you see this on the mozilla bits? basically on all platforms in the
commercial build.

to repro: open up the Preferences dialog. observe that the category tree (left
panel) is momentarily all expanded (ie, all categories displayed) then flickers
annoyingly for about 2-3sec as the parent categories are being collapsed.

ben/hyatt/jrgm, any ideas what's causing this?

Comment 1

[sairuh (rarely reading bugmail)]

keywords added...would this be easy to fix?

Comment 2

[R.K.Aa.]

confirming on linux m18 from pub/mozilla/nigthly 2000081509
In this build it seems to collapse quicker than it used to be, took longer time
in the build from the 13th,and was thus more visibly bugged, but it's still a
little "noisy".
I wonder if it's only the "advanced" cathegory that collapses today?
("Appearance" and "Navigator" opens unfolded and remain that way)

Comment 3

[Asa Dotzler [:asa]]

pretty sure this is already reported. 

Comment 4

[sairuh (rarely reading bugmail)]

asa, i couldn't find it after a few queries --if you find an earlier existing
bug, feel free to dup this. thx!

Comment 5

[R.K.Aa.]

ahh i searched as well - for all bugs, all resoutions, all components, with
words "preferences" or "prefs" in summary, altered during the past 15 days:
nothing relevant turned up.

Comment 6

[johng]

nav triage team:
nsbeta3-

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

I saw this in an 8/10/2000 build before meetzilla under FreeBSD.  The categories
(especially Advanced) open and close a few times.  This was with a fresh default
profile; first time opening prefs.

I don't notice it in Win32 2000082313

Comment 8

[R.K.Aa.]

I wonder.. if this has been fixed.
Testing on linux 2000082316 i don't see the flicker, in addition it now seems
the menu for the appropriate menus open when prefs start:

If i open from navigator: "navigator" item opens pre-unfolded and preselected.
In addition "Appearance" is also pre-unfolded, which also seems right.

If i open from mailnews it's the "mail and news" item that is unfolded and
preselected. (Again "Appearance" is pre-unfolder, not quite as required here but
not a real bug.)

If i start from Composer, composer-item is preselected and pre-unfolded.
(And "Appearance" once again.)

None of the unfolded appearances mentioned above cause flickering anymore, and
menus are presented in an easily accessible and intuitive manner.
I suspect this is boiling down to a WFM.

Comment 9

[sairuh (rarely reading bugmail)]

hrm, i no longer see the flickering with these builds/skins (all are opt
commercial):

mac 2000.08.25.04, blue or modern
winNT 2000.08.25.08, modern (blue isn't in this build)
linux 2000.08.25.08, blue or modern

marking wfm, for the nonce at least...

Comment 10

[sairuh (rarely reading bugmail)]

agh, i just saw this on linux (same bits, modern skin). now this is happening
erratically. what joy. reopening.

Comment 11

[Blake Ross]

i believe this is linux-only (wfm, 2000082508 win98), with the noted exception
that randall saw it on FreeBSD previously.  Or do you see this in mac?

Comment 12

[Asa Dotzler [:asa]]

seeing this on win32 mozilla bits 082513 on NT

Comment 13

[sairuh (rarely reading bugmail)]

happens on all platforms (i saw it today on mac looking at simon's debug build).

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

I would really like david to fix this bug.

Comment 15

[David Hyatt]

I would too.  Unfortunately, none of us has any idea why it's happening.

Comment 16

[David Hyatt]

Attachment: Keep onload handler from firing too early.

Comment 17

[David Hyatt]

Attachment: Allow open attributes to go through.

Comment 18

[Dan M]

r=danm

Comment 19

[Brendan Eich [:brendan]]

+
+   // We get notified every time a subframe is loaded. We
+  // need to properly ignore the load of subframes and only really

Nit: make the first comment-line's // line up with the second.

+  // execute our onload handler when we get a notification for ourselves
+  nsCOMPtr<nsISupports> container;
+  nsCOMPtr<nsIDocShellTreeItem> docShellAsItem, parent;
+
+  loader->GetContainer(getter_AddRefs(container));
+  // Is this a frame ?
+  docShellAsItem = do_QueryInterface(container);
+  if (docShellAsItem) {
+    docShellAsItem->GetSameTypeParent(getter_AddRefs(parent));
+  }
+  if (parent)
+    return NS_OK; // We're a subframe. Get out of dodge.

Wow, what a painful way to test for is-a-frame.  I bet it's copy-and-pasted all 
over creation, too.  It looks ok to me, though: sr=[e-mail] on it if 
you fix that comment alignment.

On to the second patch:

     if (reframe == PR_FALSE && tag && (tag.get() == nsXULAtoms::treechildren ||
-      tag.get() == nsXULAtoms::treeitem || tag.get() == nsXULAtoms::treerow ||
-      tag.get() == nsXULAtoms::treecell))
+      (tag.get() == nsXULAtoms::treeitem && aAttribute != nsXULAtoms::open) 
+      || tag.get() == nsXULAtoms::treerow || ...))

Nit: why did you switch from || at the end of a continued line to at the 
beginning?

Non-nit: this patch I don't understand based on radha's comment.  Can you walk 
me through it?  Thanks,

/be}

Comment 20

[David Hyatt]

A docloaderobserver hears about all frames of the same type that load.  It gets
its OnEndDocLoad method called for each subframe (and for the top-level doc).
Subframes are always called first, since the top-level doc won't be loaded until
the subframes are loaded.

The old code executed the first time any frame loaded, so when one of the doc's
subframes loaded, we'd go ahead and fire the onload handler early.  The new code
checks to see if the thing just loaded is a frame, and if so, it does nothing...
waiting for the notification that will eventually come in that indicates the
top-level doc has fully loaded.

Comment 21

[David Hyatt]

Fixed.

Comment 22

[sairuh (rarely reading bugmail)]

no more flicker. vrfy using opt comm *trunk* bits 2000.11.13.08 on mac, linux
and winnt.