Closed Bug 18991 Opened 25 years ago Closed 24 years ago

Splitter resizes under IFrames

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: mscott, Assigned: pavlov)

References

Details

(Whiteboard: [PDT-]fixed on mac and windows) 

Using windows build from 11/16/99.

Resizing the splitter isn't working in both the sidebar and the mailnews folder
pane. Actually it kind of works in the sidebar but the resize doesn't
occurr until after I release the mouse button. And in the mean time, the
splitter stripe is getting dragged underneath the content area and it looks
really strange.

For mailnews things are a bit worse. I can't push the splitter any further to
the right than the currently designated boundary. I can use the splitter to make
the folder pane smaller but can never make it larger. So you always lose
content space.

This worked the other day.
Whiteboard: [PDT+]
Putting on the the PDT+ radar.
OS: other → All
Hardware: PC → All
This has been a problem on Linux forever (not new in 11/16); problems similar to
what mscott describes, and in addition, problems where the splitter loses the
mouse-up and will resize any time the mouse passes over it regardless of whether
a button is pressed.
Whiteboard: [PDT+] → [PDT+] will be fixed when new web shell lands 11/??/1999
The spitter works fine except for the fact it moves under the iframes. This
happens because iframes have widgets and splitters do not. This will be fixed
when the new web shell lands and removes the widgets from iframes.

As for losing the mouse can you show me a reproducable case? I can't seem to get
this to happend on linix.
Actually splitter resizing has gotten a lot more robust just recently, and I'm
no longer losing the mouse's button state.  The iframe problem may be the only
one left.
Enlarging the Messenger folder pane seems to work in 11/22 build on Win32, Linux
and Mac.  I think this bug is purely cosmetic now.
Whiteboard: [PDT+] will be fixed when new web shell lands 11/??/1999 → will be fixed when new web shell lands 11/??/1999
Removed PDT+ annotation... it sounds like this is no longer as severe, and folks
would like it off the PDT radar.  We'll reclassify it this afternoon at the PDT
meeting.
Whiteboard: will be fixed when new web shell lands 11/??/1999 → [PDT-]will be fixed when new web shell lands 11/??/1999
Putting on the PDT- radar.
Priority: P3 → P4
Summary: [DOGFOOD] Splitter resizing broken in 11/16 builds → [DOGFOOD] Splitter resizes under IFrames
Whiteboard: [PDT-]will be fixed when new web shell lands 11/??/1999 → [PDT-]will be fixed when new web shell lands
Target Milestone: M13
changed summary to reflect remaining problem, target M13.
Travis, should we reassign this to you?
Depends on: 13374
I put this dependent on 13374.  Though I question what will happen when a given
docshell has a plugin or whatever in it.  I wonder if the splitter should not
have a widget of it's own when it is dealing with a widgeted item on either
side of it.
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Yes the splitter will slide under the plug in or applet. We will also have this
same problem with absolutely positioned things as well. The real fix is to
provide a plugin API that has clipping in it. This would be used for both
applets and plugins.
*** Bug 19987 has been marked as a duplicate of this bug. ***
moving from leftover dogfood to beta1 radar
Keywords: beta1
Summary: [DOGFOOD] Splitter resizes under IFrames → Splitter resizes under IFrames
Whiteboard: [PDT-]will be fixed when new web shell lands → will be fixed when new web shell lands
Putting on PDT+ radar for beta1.
Whiteboard: will be fixed when new web shell lands → [PDT+]will be fixed when new web shell lands
Blocks: 24700
*** Bug 24732 has been marked as a duplicate of this bug. ***
*** Bug 25423 has been marked as a duplicate of this bug. ***
I'd just like to throw my 2 cents in here and ask why the splitter doesn't just 
implement a ghost-cursor of the splitter instead of actually moving the splitter 
itself. Neither the content of the sidebar nor the content of the webpage resize 
as you move the splitter, so this would seem an ideal solution.  Add to this 
the fact that the splitter disengages from the top and bottom of the sidebar 
upon resize, and the ghost-cursor seems even more sensible. It is the current 
method of resizing panes in Communicator, as well.
The splitter was originally designed to do realtime resizing. It had been 
adapted to resize after because gecko is still not fast enough. That is why it 
moves like it does. Normally it would pull content with it. I was hoping gecko 
would be fast enough by now. I may indeed have to fix it to do true ghosting.
Whiteboard: [PDT+]will be fixed when new web shell lands → [PDT+] have fix on windows. Testing on mac and linix.
Please don't "Fix" the splitter.  The problem is the speed of the redraw of 
gecko and that must be faster for mozilla to be worth using.  We are all 
assuming mozilla will be worth using so let's have the best interface as well.
I don't see the lack of continuous, real-time reflowing of the sidebar *and* a 
complex HTML page as a serious problem. Neither Communicator nor IE reflow the 
page in realtime when a splitter is moved. Each uses a ghost splitter line. I 
think that is a reasonable solution. It's quite possible that Mozilla will never 
be quick enough to reflow full pages at the speed you expect, lbb. How long do 
you think we should wait for a reasonable solution to this issue?

Gecko's redraw is already fast (I have seen its DOM performance outpace IE 5.5). 
However, it just might not be fast enough to make a real-time resizing of the 
splitter possible. There's no shame in that.
If this is changed to be ghosting then it should be done on a flag.  Since we 
want to use this technology for building general apps, then we shouldn't break 
the ability to do realtime resizing if the content contained with in can 
support it.  In the browser case, perhaps the speed of resizing is not good 
enough to do realtime resizing, but in other windows within the client and 
perhaps in others the speed is good enough.  So I think this should be a xul 
option on the splitter to specify what type of resizing it is to be.
Pavlov this works on mac and windows. But on linux it fails. It happens because 
of a miscalculation when moving a widget. If you remove the ifdef XP_UNIX so the 
#else section fires in mozilla/layout/xul/base/src/nsSplitterFrame.xpp (line 
348) you can expose the problems. Now if you run mozilla and resize the sidebars 
splitter you will see he splitter zip across the screen. 

This happens because on line 1094 I attempt to move the view. This eventually 
calls SetPosition(..) on nsView. It then calls GetAppUnitsToDevUnits and attemps 
to move the widget to where I asked. Unfortunately it moves by some weird value 
I think its because the scale factor it gets from Linux is incorrect.
Assignee: evaughan → pavlov
Status: ASSIGNED → NEW
Whiteboard: [PDT+] have fix on windows. Testing on mac and linix. → [PDT+] fixed on mac and windows
I don't think this needs to be PDT+ since this is purly cosmetic.
Whiteboard: [PDT+] fixed on mac and windows → fixed on mac and windows
Putting on the PDT- radar for beta1.
Whiteboard: fixed on mac and windows → [PDT-]fixed on mac and windows
*** Bug 28097 has been marked as a duplicate of this bug. ***
splitters no longer resize over iframes...  they resize inplace.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
splitter now features realtime resizing on all platforms as of the 2000033113 builds. Marking VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.