Timeline



Jul 2, 2004:

10:27 AM Changeset in webkit [6958] by darin
  • 3 edits in trunk/WebKit

Reviewed by Dave.

  • fixed problem where tabsToLinks and privateBrowsingEnabled did not work with non- standard WebPreferences objects
  • WebView.subproj/WebPreferences.m: (-[WebPreferences _valueForKey:]): New helper. (-[WebPreferences _stringValueForKey:]): Use _valueForKey. (-[WebPreferences _integerValueForKey:]): Use _valueForKey. (-[WebPreferences _boolValueForKey:]): Use _valueForKey. (-[WebPreferences tabsToLinks]): Use _boolValueForKey; this is the bug fix. (-[WebPreferences privateBrowsingEnabled]): Ditto. (+[WebPreferences _setIBCreatorID:]): Use copy instead of retain for keeping an NSString.
10:03 AM Changeset in webkit [6957] by darin
  • 2 edits in trunk/WebCore

Reviewed by Dave.

  • fixed half of <rdar://problem/3709244> utf-8 meta tag not parsed when page title contains angle brackets or if </meta> tag used
  • khtml/misc/decoder.cpp: (Decoder::decode): Allow </meta> tags without deciding we are done with the header.

Jul 1, 2004:

1:41 PM Changeset in webkit [6956] by trey
  • 2 edits in trunk/WebKit

3556159 - Crashes in -[WebFrame(WebPrivate) _transitionToCommitted:] at www.mastercardbusiness.com

We know from the line number of the crash that it is due to [self parentFrame]==nil.

Looking at the HTML and that of the related bugs, they do special stuff with onload
handlers. It is no longer repro, presumably because the includes JS files changed,
as the bugs only included the top level HTML. I suspect that the problem is that the
WebFrameLoadTypeOnLoadEvent case was added, and in some weird sequence specific to
MasterCard, they hit a case where we would be in WebFrameLoadTypeOnLoadEvent mode but
not have a parent frame.

So we guard in the code against hitting a nil parentFrame, and log an error just in
case this ever crops up again and we can learn more about it.

Reviewed by Richard.

  • WebView.subproj/WebFrame.m: (-[WebFrame _transitionToCommitted:]): Guard against nil parentFrame.
10:41 AM Changeset in webkit [6955] by sullivan
  • 3 edits in trunk/WebKit

Reviewed by Trey.

  • fixed these bugs: <rdar://problem/3709110> REGRESSION (Tiger): Pressing Tab key to move focus onto links skips every other link <rdar://problem/3692576> focus ring is in odd place after clicking RSS button with "Tab to links" enabled

WebHTMLView has some trickery by which we advance the focused link when nextKeyView
or previousKeyView is called within nextValidKeyView or previousValidKeyView. This
broke in Tiger because AppKit now (sometimes at least) calls nextKeyView more than
once within nextValidKeyView. Fixed 3709110 by making sure we only advance the focus
once within a call to nextValidKeyView or previousValidKeyView.

Also, this same trickery didn't work right with hidden views. Fixed 3692576 by checking
whether the view is hidden and bypassing the focus-moving trickery in that case.

  • WebView.subproj/WebHTMLViewInternal.h: renamed inNextValidKeyView -> nextKeyViewAccessShouldMoveFocus
  • WebView.subproj/WebHTMLView.m: (-[WebHTMLView nextKeyView]): now clears nextKeyViewAccessShouldMoveFocus (-[WebHTMLView previousKeyView]): ditto (-[WebHTMLView nextValidKeyView]): now doesn't set focus-moving trigger ivar if view is hidden or has hidden ancestor (-[WebHTMLView previousValidKeyView]): ditto

Jun 30, 2004:

7:07 PM Changeset in webkit [6954] by trey
  • 14 edits in trunk

WebCore:

Dragging within a web view should be allowed to start when the window isn't key.

A few months ago, Chris made this work, but it relied on the fact that all dragging
was done in WebKit. When WebCore got involved in dragging, it was broken. Now we
have a new scheme that gets it working again that properly involves WebCore.

The general idea is that when AK asks us whether to accept the first mouse and do
"delayed window ordering", we must consult WC to see if we might start a drag. In
addition, instead of these drags in non-active windows being started as a special
case in WK, they go through the normal WK-WC drag machinery.

Reviewed by John.

  • khtml/khtml_part.cpp: (KHTMLPart::shouldDragAutoNode): New x,y args.
  • khtml/khtml_part.h:
  • khtml/rendering/render_object.cpp: (RenderObject::draggableNode): Pass through new x,y args.
  • khtml/rendering/render_object.h:
  • kwq/KWQKHTMLPart.h: (KWQKHTMLPart::setActivationEventNumber): New setter.
  • kwq/KWQKHTMLPart.mm: (KWQKHTMLPart::KWQKHTMLPart): Init new ivar. (KWQKHTMLPart::eventMayStartDrag): New routine that checks if we might start a drag in response to a mouseDown. (KWQKHTMLPart::khtmlMouseMoveEvent): Pass x,y to the routine that finds a draggable node. This eventually gets back up to WK's _mayStartDragAtEventLocation:. Delay requirement when dragging the selection now implemented here. (KWQKHTMLPart::khtmlMouseReleaseEvent): Must avoid changing the selection if we wind up here as part of the first click in a window (because we started handling the click to possible start a drag, but that never came through). (KWQKHTMLPart::mouseDown): Save away event timestamp. (KWQKHTMLPart::shouldDragAutoNode): Pass location up to WK instead of the most recent event we stashed.
  • kwq/WebCoreBridge.h:
  • kwq/WebCoreBridge.mm: (-[WebCoreBridge setActivationEventNumber:]): Trivial glue. (-[WebCoreBridge eventMayStartDrag:]): Ditto.

WebKit:

Dragging within a web view should be allowed to start when the window isn't key.

A few months ago, Chris made this work, but it relied on the fact that all dragging
was done in WebKit. When WebCore got involved in dragging, it was broken. Now we
have a new scheme that gets it working again that properly involves WebCore.

The general idea is that when AK asks us whether to accept the first mouse and do
"delayed window ordering", we must consult WC to see if we might start a drag. In
addition, instead of these drags in non-active windows being started as a special
case in WK, they go through the normal WK-WC drag machinery. Finally to work in
frames we have to drill to the deepest hit view in acceptsFirstMouse, because previous
hacks to hitTest make the top-most WebHTMLView field all events for its view tree
(which leads to it fielding all acceptFirstMouse messages too).

Reviewed by John.

  • WebCoreSupport.subproj/WebBridge.m: (-[WebBridge mayStartDragAtEventLocation:]): Glue change for new arg type.
  • WebView.subproj/WebHTMLView.m: (-[WebHTMLView _startDraggingImage:at:operation:event:sourceIsDHTML:DHTMLWroteData:]): firstMouseDownEvent ivar is no longer needed. (-[WebHTMLView _mayStartDragAtEventLocation:]): Receives a location instead of a drag event, since we need to do this work when we have no drag event. This means the check of the delay for text dragging is moved down to WebCore. (-[WebHTMLView acceptsFirstMouse:]): Respond based on whether we might do a drag. This includes drilling to the deepest view the event hits, whereas we used to only respond considering the topmost WebHTMLView. (-[WebHTMLView shouldDelayWindowOrderingForEvent:]): Ditto. (-[WebHTMLView mouseDown:]): Get rid of special case where some activating mouseDown events weren't sent to WC. We need to go through the whole pipeline now to get a drag started properly. (-[WebHTMLView mouseDragged:]): Ditto, let WC start the drag. (-[WebHTMLView mouseUp:]): firstMouseDownEvent ivar is no longer needed.
  • WebView.subproj/WebHTMLViewInternal.h:
  • WebView.subproj/WebHTMLViewPrivate.h:
10:14 AM Changeset in webkit [6953] by trey
  • 2 edits in trunk/WebCore

Need to tighten up JS error checking for requesting drag props
in the wrong cases.

Reviewed by John.

  • khtml/ecma/kjs_events.cpp: (Clipboard::getValueProperty): Assert if someone somehow set dropEffect or effectAllowed and it's a copy/paste clipboard instead of a dragging clipboard. (Clipboard::putValue): Don't let anyone set dropEffect or effectAllowed on a copy/paste clipboard. (ClipboardProtoFunc::tryCall): Disallow setting dragImage on a copy/paste clipboard.

Jun 29, 2004:

4:37 PM Changeset in webkit [6952] by trey
  • 4 edits in trunk/WebCore

DHTML dragging - source should have access to the operation chosen
by the destination.

Reviewed by John

  • kwq/KWQKHTMLPart.h:
  • kwq/KWQKHTMLPart.mm: (KWQKHTMLPart::dragSourceEndedAt): Set the destination's operation on the clipboard.
  • kwq/WebCoreBridge.mm: (-[WebCoreBridge dragExitedWithDraggingInfo:]): For completeness we set the source op for the ondragexit event. (-[WebCoreBridge concludeDragForDraggingInfo:]): Ditto for the drop event. (-[WebCoreBridge dragSourceEndedAt:operation:]): Pass through of operation.
Note: See TracTimeline for information about the timeline view.