Closed Bug 20226 Opened 25 years ago Closed 25 years ago

Sidebar Iframe contents not drawing on grippy open.

Categories

(SeaMonkey :: Sidebar, defect, P3)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jelwell, Assigned: eric)

References

Details

(Whiteboard: Fixed awaiting checkin) 

Steps to reproduce.
1) Launch Mozilla
2) Open the sidebar.
3) Click on Bookmarks.
2) click on grippy to close sidebar.
3) click on grippy to open sidebar.

Expected Results:
Bookmarks are drawn in the sidebar.

Actual Results:
Sidebar is empty except the section titles.

To redraw the sidebar contents:
a) drag grippy a little.
OR
b) click on one a section title (other than the one you were on) then click back
onto the section you were originally on.

This was tested on nightly build 1999112808 on Windows NT.
And also on a recent Linux nightly build.
a dup of bug 18406?
I don't think it's the same. This bug doesn't exist on M11 (which the other bug
predates). Also, in bug 18406 one can't get the sidebar to redraw simply by
dragging grippy. So I think bug 18406 is a similar yet different bug. Relying on
possibly some but not all of the same problems.
This looks like a duplicate of bug 17106. The iframes used in the sidebar are
refusing to hide.
Bug 17106 seems to be talking about the "sidebar" as in a (html) frame of some
web page. Bug 17106 also points out that it works fine on Windows, and has a URL
that seems to cause the problem. I am conjecturing on the Bug 17106 because the
URL no longer works, and the comments seem undirected and confused.

However This bug (22026) does not require a web page, and is not a html FRAME
tag, but rather deals with mozilla's customizable "My Panels" sidebar.
Ok, 17106 was fixed over the weekend. With today's build I see the behavior you
are talking about.
*** Bug 20636 has been marked as a duplicate of this bug. ***
I need to find a better owner for this bug.
Assignee: slamm → trudelle
Peter, I am not sure who should own this. It looks like the iframe in the
sidebar is not getting redrawn when the sidebar is expanded. Could be evaughan
or ????
Assignee: trudelle → evaughan
Whiteboard: needs evaughan triage
reproduced in today's opt comm build on win98, reassigning to evaughan for
triage.
Status: NEW → ASSIGNED
Target Milestone: M14
This continues to be a nuisance on 2000010908 WinNT build.
I think this bug is dependent on bug 13047. In paticular I think this line of
code isn't working properly
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/contentframe.js#58

Since this paticular bug doesn't seem important I'm trying to fix it at home. If
it turns out that this bug isn't dependant on bug 13047, I'll let you know. I'll
post updates if I get anywhere on it also.
*** Bug 22214 has been marked as a duplicate of this bug. ***
hmm. bug 22214 has a test case and more discussion. Maybe I should have marked
duplicate in the other direction.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
this is working for me using 1/19 builds, marking fixed, perhaps by some of
slamm's changes...
Status: RESOLVED → VERIFIED
marking verified, jelwell please yell if you see different
Status: VERIFIED → REOPENED
Oh god, it happened all so fast! Resolved and verified in one minute.
Anyways, nope, it's not working. I'm aware of the code changes that have been
going on behind the scenes - Which aren't solutions, they're hacks (albeit the
same hack I was going to perform: adjusting the frame size on open).

Anyways, on build 2000011908 this still doesn't work 100%. Try opening and
closing it more than few times. You'll find that eventually it opens and your
bookmarks aren't drawn.
Resolution: FIXED → ---
I meant to mention that it's still not working on _WinNT_ build 2000011908. I
haven't tried it on any other builds.
Okay, I see it sometimes also on Linux. A resize of the sidebar also causes the 
content to show.
OS: Windows NT → All
Hardware: PC → All
Whiteboard: needs evaughan triage
Blocks: 24700
putting on beta1 radar
Status: REOPENED → ASSIGNED
Whiteboard: Fixed awaiting checkin
From what I've seen of the code, I think this is dependent upon bug 13047
"CSS-Visibility can´t be changed". Marking so.
Depends on: 13047
bug 18962, which I think is a dupe of bug 13047 seems to talk directly about
this bugs problem.

Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
marking verified. There is a new bug filed that if you start with sidebar 
closed, the first time you open it no content shows
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.