WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
4840
Frames only resize wider, can't make them narrower
https://bugs.webkit.org/show_bug.cgi?id=4840
Summary
Frames only resize wider, can't make them narrower
Douglas Livingstone
Reported
2005-09-04 06:00:13 PDT
1) Visit
http://api.rubyonrails.com/
2) Drag the vertical divider to the right 3) Drag it back to the left Expected: Gets narrower Actual: Nothing happens
Attachments
3 frame testcase
(162 bytes, text/html)
2005-09-07 03:11 PDT
,
Douglas Livingstone
no flags
Details
Don't lose track of the resizing frameset
(4.30 KB, patch)
2006-03-03 16:04 PST
,
mitz
darin
: review-
Details
Formatted Diff
Diff
Revised patch, including manual test and change log
(6.60 KB, patch)
2006-03-04 12:57 PST
,
mitz
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Oliver Hunt
Comment 1
2005-09-07 02:46:53 PDT
confirming, needs a minimised testcase though
Douglas Livingstone
Comment 2
2005-09-07 03:11:48 PDT
Created
attachment 3794
[details]
3 frame testcase
Alexey Proskuryakov
Comment 3
2006-03-03 06:59:11 PST
***
Bug 5452
has been marked as a duplicate of this bug. ***
Alexey Proskuryakov
Comment 4
2006-03-03 07:04:25 PST
Reassigning to webkit-unassigned, to make sure more people see this. We need a separate P1 bug for the issue mentioned in
bug 5452 comment 1
...
mitz
Comment 5
2006-03-03 16:04:36 PST
Created
attachment 6833
[details]
Don't lose track of the resizing frameset [Please comment and r- anyway since this is missing a test and a change log entry]. This bug is caused by the fact that when the splitter is dragged to the left, the mouse moved (and ultimately mouse released) events are being sent to the inner frameset (on the left) instead of the currently resizing outer frameset. The fix is to dispatch all mouse events to the currently-resizing frameset. There may be some way to make hitTest give the right answer, but I don't think RenderFrameSet::nodeAtPoint() can be modified in a helpful way.
Darin Adler
Comment 6
2006-03-04 11:47:31 PST
Comment on
attachment 6833
[details]
Don't lose track of the resizing frameset We would like a capturing mechanism that works for all drags. But adding one specifically for the frameset resizing seems fine for now. It's not good to add stuff about resizing to the DOM, though. This should stay in the view system (rendering and FrameView). + DocumentImpl *d = getDocument(); + FrameView *w = d ? d->view() : 0; + if (w) + w->setResizingFrameSet(e ? this : 0); getDocument no longer ever returns 0 -- nodes now reference their document -- so we don't need a nil-check on the document. I'd also like to see the FrameView* style used instead of FrameView * as per our style guidelines. But this function should go. RenderFrameSet::setResizing should handle this directly, calling the FrameView. You don't need a boolean in the renderer or the DOM element. Nice fix in hoverTimerFired.
mitz
Comment 7
2006-03-04 11:51:56 PST
(In reply to
comment #6
)
> Nice fix in hoverTimerFired.
Oops! That part comes from a different patch (
bug 7555
) and doesn't belong here. I'll redo the patch based on the other comments.
mitz
Comment 8
2006-03-04 12:57:47 PST
Created
attachment 6853
[details]
Revised patch, including manual test and change log
Darin Adler
Comment 9
2006-03-04 13:13:30 PST
Comment on
attachment 6853
[details]
Revised patch, including manual test and change log r=me
Darin Adler
Comment 10
2006-03-04 13:14:05 PST
Comment on
attachment 6853
[details]
Revised patch, including manual test and change log r=me
Alexey Proskuryakov
Comment 11
2006-03-05 01:34:28 PST
Landed,
r13135
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug