Closed Bug 19230 Opened 26 years ago Closed 23 years ago

Sidebar doesn't refresh when right window border overlaps it

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: aagno, Assigned: eric)

References

Details

If you have the sidebar open, and you move the right border of the browser window over the My Panels sidebar, as if to resize the browser window, then move the border back to the right, the sidebar doesn't get refreshed. This is on NT 4 (SP=latest - 1, whatever it is) with Milestone 11. Andrew.
Yes, I see this too using an 11/18 build on win98. Does not happen on linux.
Assignee: slamm → troy
Component: Sidebar → Layout
I see this as well. Reassigning to layout.
Why is this a layout issue if it works on Linux and not on NT? All of the layout code is XP...
Assignee: troy → slamm
Component: Layout → XPApps
I don't know what is meant by "right border of the browser window", but I assume it's taking about the vertical bar separating sidebar and the Web page. If I move the vertical bar it paints "underneath" the sidebar content and I don't see the problem described Regradless, it doesn't seem like a layout issue to me, especially if it works on some platforms and not others. Maybe then it is a widget issue I don't know what RDF (I assume) is used to do the sidebar, and so I can't suggest where the specific problem is
The right border of the browser window refers to the bit of the browser window that is to the right of the scroll bar, which allows you to resize the window in NT--this is the entire window, not just the sidebar. Oh, and this all refers to NT, of course.
Assignee: slamm → trudelle
Component: XPApps → XP Toolkit/Widgets
Summary: sidebar doesn't refresh when right window border overlaps it → Sidebar doesn't refresh when right window border overlaps it
Ok, passing to toolkit team. To reproduce, take the right edge of the browser window and drag it past the vertical splitter of the sidebar (over the sidebar). Without letting go, make the window wider again. The iframe content does not refresh.
Assignee: trudelle → troy
Component: XP Toolkit/Widgets → Layout
How is this a widget issue? there are no widgets involved in reproducing this bug. The difference in platform behavior is no doubt because Windows obscures the sidebar during the drag, whereas Linux and Mac do not. reassigning to Layout
Assignee: troy → trudelle
Let's not go through this again. The bug was assigned to layout even though it was reported that it worked on Linux and not on NT. All of layout is XP, and therefore if it works on one platform and not another it's highly unlikely it's a problem in the all-XP layout code And yes there are widgets involved. At least until evaughan switches us over to gfx scrollbars there are widgets associated with scroling views
I reproduced this using GFX scrollbars, which by the way are also XP. Troy, are you saying that the platform difference couldn't be caused by the fact that only Windows obscures window content during such a resize? It seems like there is no need for reflow, or even a repaint, of the sidebar on Mac & Linux in this scenario.
The bug as originally reported claimed that the problem occured on NT and that it worked fine on Linux. If that's the case, then it probably isn't a layout bug because layout is all XP code. I don't know what you mean by "only Windows obscures window content during a resize". The problem is everyone just assumes these kind of problems are layout issues without trying to narrow the problem down or come up with a small test case If it's really a layout issue, then it should be reproducible with a small HTML or XML example. We got a large number of layout bugs every day and it's very time consuming to try and narrow down problems like this. I have no idea how the sidebar works (e.g., is it implemented using framesets or boxes) at all The problem could be in the widget code (and how paint messages are processed), view code, core layout code, or XUL code
Assignee: trudelle → kmcclusk
What I mean is that when you follow the steps to reproduce this bug, repainting of the sidebar is only needed on MS Windows. Dragging the right edge of the window on Mac and Linux (at least RH 6/Gnome/Enlightenment)just drag an outline, they don't change the size of the window until you release. Perhaps you're right that this is more likely in the paint message processing. reassigning to kmcclusk. Kevin, could this be caused by your recent elimination of multiple repaints when resizing?
Status: NEW → ASSIGNED
Target Milestone: M13
The sidebar will refresh if the window is made both wider and higher on the resize after obscuring the sidebar. When the window is made wider WIN32 does not generate any paint events for the sidebar to refresh it. I verified this using spy++. This is because the sidebar has a fixed width so it's size has not changed. There are optimizations in the box code to prevent painting and reflowing in this situation. The box layout code should invalidate the sidebar to cause a repaint under this condition. Linux and Mac may be generating resize\paint events for all child windows even though they have not changed size, and thats why they are being refreshed. (It is a known bug that Linux is generating too many NS_SIZE events.) They should not generate a resize or paint event for a child window when it's parent window is resized. I think box layout needs to changed to generate an invalidate and Linux and Mac should suppress the generation of paint/resize messages under this circumstance. CC'ing evaughan. Eric: What do you think about this?
Target Milestone: M13 → M15
Moving to M15
Assignee: kmcclusk → evaughan
Status: ASSIGNED → NEW
Eric please look at my 1999-12-13 17:17 comment. I think this is a box layout issue, so I'm reassigning it to you.
*** Bug 23443 has been marked as a duplicate of this bug. ***
*** Bug 29760 has been marked as a duplicate of this bug. ***
*** Bug 29948 has been marked as a duplicate of this bug. ***
fixed
Status: NEW → ASSIGNED
fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Is this in any of the daily builds, or will it just show up in M15? I'm using 2000032308 on my NT box, and it still shows this behaviour. Andrew.
Okay, since I didn't get any response, I'll assume it's supposed to show up in M15 and isn't in any of the daily builds, as this still happens in Build ID: 2000033008. Andrew.
it is supposed to show up in the daily builds, if you are still seeing this, then please re-open
Okay, I see this in WinNT still, but not Win98. I tested on Win98 with Build 2000040108, and on WinNT one with the builds listed previously. WinNT is WinNT 4 SP 5. Andrew.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
On the 2000040415 build, if I make the sidebar the minimum size by dragging its right border as far to the left as I can, then drag the browser window's right border over the sidebar and back again, the sidebar refreshes properly. If I make the sidebar a bit bigger, though, and drag the browser border again, then the sidebar does not refresh between the sidebar border, and the right edge of the tabs in the sidebar. Andrew.
Mass-moving most M15 bugs to M16
Target Milestone: M15 → M16
qa contact to shrir for sidebar bugs
QA Contact: paulmac → shrir
This only affects users when 1) "update window contents while resizing" is in effect 2) If the user narrows the window to ~100px moving to m18
Target Milestone: M16 → M18
*** Bug 30079 has been marked as a duplicate of this bug. ***
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
(per trudelle). mass-moving all evaughan non-nsbeta3+ bugs to 'Future' milestone
Target Milestone: M21 → Future
Does this bug still exist?
URL: doesn't matter
WFM. Sidebar gets refreshed. Also there is minimum width of the Sidebar - we can not decrease Browser or Mail smaller than this. I check it on Win2K.
WFM.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.