8634 - Sidebar expand/collapse draws slowly

Status: RESOLVED INVALID

(Core :: Layout, defect, P3)

Description

[pcollins]

If you expand the flash panel by clicking on the little grippy.
The panel expands to about 3/4 of the content are then contracts to
the target position of about 1/4 of the content area.

If you then click on the grippy again, the content area
redraws entirely and sluggishly, before collapsing.

It seems there is a rendering lapse or default call, before any width or size
paramater arguments are passed to the function that expands the panel.

Comment 1

[leger]

ARe you talking about the Sidebar? And what build are you using?  I think this
is a known bug with an older version.

pcollins, please read the following to supply us with more complete info to help
you out here :-)
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 2

[Paul MacQuiddy]

I think I see what you are talking about, though it is very quick and subtle.
The opening and closing of sidebar is not especially smooth and clean. I imagine
this belongs to the gecko fellows.

Comment 3

[pcollins]

I am using windows binary build for 6/21/99. Sorry Next time I will use buid #.
It may be quick and subtle on a faster machine, however I am viewing this on a
slow machine and it lets me see what is actually happening when you open or
close the side bar. It is definately a rendering problem, but I believe it is
not easily detected on a fast machine.

Comment 4

[Steve Lamm]

Changing the component to layout.

Comment 5

[rickg]

David -- this one should start with you I think.

Comment 6

[fenella]

Win32(1999-07-07-08 m8)
Using 7/7 build on Win_nt, I am unable to expand Sidebar

Comment 7

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

I've got this to work, I think. Here's a fix. Somewhat of a cheap hack, and is
probably not *all* that is required, but it does the trick for the impatient:

actual JS and XUL files at:
http://homepages.ihug.co.nz/~rgoodger/lizard/patches/contentframe.js
http://homepages.ihug.co.nz/~rgoodger/lizard/patches/contentframe.xul

description:
every time toggle_open_close() is executed, the sidebar frame's src is reset.
this essentially reloads it. By taking these lines out, and putting the src
loading elsewhere (so its only executed on startup), the speed lag goes away
completely.

What makes this hack so cheap:
1) you have to set the src of the sidebarframe in the actual XUL to the
sidebar-browser.xul (rather than about:blank as in the original, and setting
later in JS)
2) you need to set the src again in the javascript (for some odd reason), and it
must be set inside toggle_open_close() (don't ask me o_O)
3) and even with the improvements, the sidebar will not pop out at all until its
contents have loaded. This is the worst problem.

So I'm not confident enough to mark this fixed, just adding these thoughts and
the code so anyone interested can try it out.

Note that by not reloading the sidebar, this solution also offers a partial
solution for bug 8642: http://bugzilla.mozilla.org/show_bug.cgi?id=8642, which
talks to sidebar content persistence. (Persistence is only for the session
though, there's no code to save settings between sessions).

Comment 8

[David Hyatt]

My hands have deteriorated to the point where I can no longer type.  I need
help.  If you think you can fix this bug on your own, please take it away from
me.  If you'd like to volunteer to be my hands for a specific bug, then I'll be
happy to come up to your cube and sit with you and fix the bug (assuming you
have the patience for that).

Comment 9

[David Hyatt]

frameset drawing is covered in plenty of other places.  I don't feel that this
bug even needs to exist. It's covered by others.

Comment 10

[shrirang khanzode]

sorry fot the spam, changing QA contact.