2007-07-17  Mark Rowe  <mrowe@apple.com>

        Gdk build fix.

        * platform/gdk/ChromeClientGdk.h:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24348 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Adam.

        Move more functions from kjs_window to DOMWindow and auto-generate
        the bindings for them.

        * bindings/js/kjs_window.cpp:
        (KJS::WindowFunc::callAsFunction):
        * bindings/js/kjs_window.h:
        (KJS::Window::):
        * page/DOMWindow.cpp:
        (WebCore::DOMWindow::print):
        (WebCore::DOMWindow::stop):
        (WebCore::DOMWindow::alert):
        (WebCore::DOMWindow::confirm):
        (WebCore::DOMWindow::prompt):
        (WebCore::DOMWindow::find):
        * page/DOMWindow.h:
        * page/DOMWindow.idl:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24350 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Adam and Maciej.

        Move the frameElement attribute from kjs_window to DOMWindow and
        auto-generate the bindings for it. 

        * bindings/js/kjs_window.cpp:
        (KJS::Window::getValueProperty):
        * bindings/js/kjs_window.h:
        (KJS::Window::):
        * bindings/scripts/CodeGeneratorJS.pm:
        * page/DOMWindow.cpp:
        (WebCore::DOMWindow::frameElement):
        (WebCore::DOMWindow::devicePixelRatio):
        * page/DOMWindow.h:
        * page/DOMWindow.idl:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24351 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Maciej.

        Fix for <rdar://problem/5334818> Support IME reconversion in windows

        Also includes a small amount of IME refactoring.

        * WebView.cpp:
        (WebView::onIMERequestCharPosition):
        (WebView::onIMERequestReconvertString):
        (WebView::onIMERequest):
        * WebView.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24352 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests:

        Reviewed by Sam Weinig.
        
        Tests for <rdar://problem/5334483> REGRESSION: JavaScript-induced loads
        not added to back/forward list

        * fast/history/location-assign-adds-history-item-expected.txt: Added.
        * fast/history/location-assign-adds-history-item.html: Added.
        * fast/history/location-href-set-adds-history-item-expected.txt: Added.
        * fast/history/location-href-set-adds-history-item.html: Added.
        * fast/history/location-replace-adds-history-item-expected.txt: Added.
        * fast/history/location-replace-adds-history-item.html: Added.
        * fast/history/location-set-adds-history-item-expected.txt: Added.
        * fast/history/location-set-adds-history-item.html: Added.
        * fast/history/window-open-adds-history-item-expected.txt: Added.
        * fast/history/window-open-adds-history-item.html: Added.
        * fast/history/window-open-adds-history-item2-expected.txt: Added.
        * fast/history/window-open-adds-history-item2.html: Added.
        * http/tests/navigation/redirect-load-no-form-restoration-expected.txt:
        Updated results. Adding a history entry here is correct behavior.

WebCore:

        Reviewed by Sam Weinig.
        
        Fixed <rdar://problem/5334483> REGRESSION: JavaScript-induced 
        window.open loads not added to back/forward list
        
        I did an audit of our history rules in loading and tried to establish
        some sane uniformity.
        
        The uniform rule is:
            - HTTP redirects and HTTP redirects simulated by <meta http-equiv>
            add a history item if and only if the redirect takes > 1 second.
            - Other navigations, including JavaScript navigations, always
            add a history item, except for location.replace navigations.

        In the future, we'll want to refine the second case to be more like the
        first. I've filed <rdar://problem/5339292> about that.

        * bindings/js/JSHTMLDocumentCustom.cpp:
        (WebCore::JSHTMLDocument::setLocation): Don't pass 'true' for 
        userGesture unconditionally. userGesture is used to determine popup 
        blocking, not history item creation.

        * bindings/js/kjs_window.cpp: Pass 'false' for lockHistory in all loads
        except location.replace, which intends to lock history.

        * loader/FrameLoader.cpp: Distinguish between lockHistory and 
        userGesture. The former determines whether a new history item gets
        created. The latter determines whether JavaScript can open popup
        windows. Start passing these variables in functions that used to
        swallow or conflate them.
        
        (WebCore::FrameLoader::requestFrame): Pass 'true' for lockHistory here
        because that's usually correct when setting the 'src' attribute of a
        child frame, and we want to avoid regressing <rdar://problem/4921797>.

        (WebCore::FrameLoader::load): Use the lockHistory variable to determine
        whether to start a history-creating load. Using userGesture for this
        purpose is wrong, as explained above.

        * loader/FrameLoader.h: Renamed one variant of scheduleRedirection to
        scheduleHTTPRedirection because the behavior there of measuring elapsed
        time is specific to the HTTP redirection case.

        * page/ContextMenuController.cpp:
        (WebCore::ContextMenuController::contextMenuItemSelected): lockHistory
        can always be false here because this navigation is never the result of
        a redirection.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24353 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Adam Roben.

        Move self, opener, parent, top, window, and frames from kjs_window
        to DOMWindow and auto-generate the bindings for them.

        * bindings/js/kjs_window.cpp:
        (KJS::Window::getValueProperty):
        * bindings/js/kjs_window.h:
        (KJS::Window::):
        * page/DOMWindow.cpp:
        (WebCore::DOMWindow::self):
        (WebCore::DOMWindow::opener):
        (WebCore::DOMWindow::parent):
        (WebCore::DOMWindow::top):
        * page/DOMWindow.h:
        (WebCore::DOMWindow::window):
        (WebCore::DOMWindow::frames):
        * page/DOMWindow.idl:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24354 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Fixed a bunch of layout test failures I just caused.
        
        Made the tests I just added into http test to make their results 
        universal.
        
        Also checked in the result change I forgot to check in last time.

        * fast/history/location-assign-adds-history-item-expected.txt: Removed.
        * fast/history/location-assign-adds-history-item.html: Removed.
        * fast/history/location-href-set-adds-history-item-expected.txt: Removed.
        * fast/history/location-href-set-adds-history-item.html: Removed.
        * fast/history/location-replace-adds-history-item-expected.txt: Removed.
        * fast/history/location-replace-adds-history-item.html: Removed.
        * fast/history/location-set-adds-history-item-expected.txt: Removed.
        * fast/history/location-set-adds-history-item.html: Removed.
        * fast/history/window-open-adds-history-item-expected.txt: Removed.
        * fast/history/window-open-adds-history-item.html: Removed.
        * fast/history/window-open-adds-history-item2-expected.txt: Removed.
        * fast/history/window-open-adds-history-item2.html: Removed.
        * http/tests/navigation/location-assign-adds-history-item-expected.txt: Copied from fast/history/location-assign-adds-history-item-expected.txt.
        * http/tests/navigation/location-assign-adds-history-item.html: Copied from fast/history/location-assign-adds-history-item.html.
        * http/tests/navigation/location-href-set-adds-history-item-expected.txt: Copied from fast/history/location-href-set-adds-history-item-expected.txt.
        * http/tests/navigation/location-href-set-adds-history-item.html: Copied from fast/history/location-href-set-adds-history-item.html.
        * http/tests/navigation/location-replace-adds-history-item-expected.txt: Copied from fast/history/location-replace-adds-history-item-expected.txt.
        * http/tests/navigation/location-replace-adds-history-item.html: Copied from fast/history/location-replace-adds-history-item.html.
        * http/tests/navigation/location-set-adds-history-item-expected.txt: Copied from fast/history/location-set-adds-history-item-expected.txt.
        * http/tests/navigation/location-set-adds-history-item.html: Copied from fast/history/location-set-adds-history-item.html.
        * http/tests/navigation/redirect-load-no-form-restoration-expected.txt:
        * http/tests/navigation/window-open-adds-history-item-expected.txt: Copied from fast/history/window-open-adds-history-item-expected.txt.
        * http/tests/navigation/window-open-adds-history-item.html: Copied from fast/history/window-open-adds-history-item.html.
        * http/tests/navigation/window-open-adds-history-item2-expected.txt: Copied from fast/history/window-open-adds-history-item2-expected.txt.
        * http/tests/navigation/window-open-adds-history-item2.html: Copied from fast/history/window-open-adds-history-item2.html.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24355 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Forgot to do the delete half of the file move. Oops.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24356 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Adam.

        Fix for <rdar://problem/5339416> Candidate window does not
                appear in the correct location for japanese IME

        * WebView.cpp:
        (WebView::prepareCandidateWindow):
          We now use an exclusion zone so that the composition window never 
          overlaps the composition string
        (WebView::onIMERequestCharPosition):
          Correctly handle character offsets marked regions



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24357 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        * http/tests/navigation/multiple-back-forward-entries-expected.txt: Updated results to
        match what I see locally and what we see on the buildbot. Geoff, please double-check that
        these new results are correct.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24361 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Darin.

        - Make HTMLFrameOwnerElement::contentWindow() return a DOMWindow instead of a Frame
        - Remove the unnecessary hack in HTMLFrameElement.idl and HTMLIFrameElement.idl that
          converted from Frame to Window now that it is not necessary.
        - Remove now unused [NullCheck] extended attribute from CodeGeneratorJS.pm.

        * bindings/scripts/CodeGeneratorJS.pm:
        * html/HTMLDocument.idl:
        * html/HTMLFrameElement.idl:
        * html/HTMLFrameOwnerElement.cpp:
        (WebCore::HTMLFrameOwnerElement::contentWindow):
        * html/HTMLFrameOwnerElement.h:
        * html/HTMLIFrameElement.idl:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24362 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests:

        Reviewed by Maciej.
        Landed by Darin.

        - test for http://bugs.webkit.org/show_bug.cgi?id=14569
          Repro crash due to saved state not being cleared when select and textarea elements are adopted by another document
          and for http://bugs.webkit.org/show_bug.cgi?id=13701
          REGRESSION (r21431): Reproducible crash resulting from calling adoptNode on a password field

        * fast/forms/saved-state-adoptNode-crash-expected.txt: Added.
        * fast/forms/saved-state-adoptNode-crash.html: Added.

WebCore:

        Reviewed by Mitz.

        - fix http://bugs.webkit.org/show_bug.cgi?id=14569
          Repro crash due to saved state not being cleared when select and textarea elements
          are adopted by another document

        Test: fast/forms/saved-state-adoptNode-crash.html

        * dom/Document.h:
        (WebCore::Document::registerFormElementWithState): Updated parameter type to be
        HTMLFormControlElementWithState.
        (WebCore::Document::unregisterFormElementWithState): Ditto.
        Also removed isFormElementRegistered function and changed the type of the
        m_formElementsWithState ListHashSet.
        * dom/Document.cpp: (WebCore::Document::formElementsState): Updated to use new type,
        for set contents and to use new saveState() function and only save state for elements
        that return true.

        * html/HTMLGenericFormElement.h: Added HTMLFormControlElementWithState class,
        derived from HTMLGenericFormElement, and moved down all the behavior related to
        saving form control element state. Also removed the unnecessary default parameter
        to the HTMLGenericFormElement constructor.
        * html/HTMLGenericFormElement.cpp:
        (WebCore::HTMLFormControlElementWithState::HTMLFormControlElementWithState): Added.
        Calls registerFormElementWithState.
        (WebCore::HTMLFormControlElementWithState::~HTMLFormControlElementWithState): Added.
        Calls unregisterFormElementWithState.
        (WebCore::HTMLFormControlElementWithState::willMoveToNewOwnerDocument): Added.
        Calls unregisterFormElementWithState.
        (WebCore::HTMLFormControlElementWithState::didMoveToNewOwnerDocument): Added.
        Calls registerFormElementWithState.
        (WebCore::HTMLFormControlElementWithState::closeRenderer): Moved to this class from
        the base class.

        * html/HTMLInputElement.h: Updated the base class name and overrode saveState instead
        of stateValue.
        * html/HTMLInputElement.cpp: Updated the base class name.
        (WebCore::HTMLInputElement::init): Removed the call to registerFormElementWithState.
        (WebCore::HTMLInputElement::~HTMLInputElement): Removed the call to
        unregisterFormElementWithState. Also changed the code to only call the
        unregisterForDidRestoreFromCacheCallback function for type PASSWORD (consistency
        and efficiency).
        (WebCore::HTMLInputElement::setInputType): Removed calls to registerFormElementWithState
        and unregisterFormElementWithState; we now let the element stay registered and simply
        don't save or restore state for password fields.
        (WebCore::HTMLInputElement::saveState): Updated function name and signature to replace
        the old stateValue function. Returns false for password fields.
        (WebCore::HTMLInputElement::willMoveToNewOwnerDocument): Removed the call to
        unregisterFormElementWithState.
        (WebCore::HTMLInputElement::didMoveToNewOwnerDocument): Removed the call to
        registerFormElementWithState.

        * html/HTMLSelectElement.h: Updated the base class name and overrode saveState instead
        of stateValue.
        * html/HTMLSelectElement.cpp: Updated the base class name.
        (WebCore::HTMLSelectElement::HTMLSelectElement): Removed the call to
        registerFormElementWithState.
        (WebCore::HTMLSelectElement::~HTMLSelectElement): Removed the call to
        unregisterFormElementWithState.
        (WebCore::HTMLSelectElement::saveState): Updated function name and signature to
        replace the old stateValue function.
        (WebCore::HTMLSelectElement::setLength): Updated to use document() instead of
        ownerDocument(); the latter is just a slower virtual-function way of doing the
        same thing in all cases except for Document and XPathNamespace.

        * html/HTMLTextAreaElement.h: Update the base class name, overrode saveState instead
        of stateValue, and removed the now-unnecessary explicit destructor.
        * html/HTMLTextAreaElement.cpp: Updated the base class name.
        (WebCore::HTMLTextAreaElement::HTMLTextAreaElement): Removed the call to
        registerFormElementWithState.
        (WebCore::HTMLTextAreaElement::saveState): Updated function name and signature to replace
        the old stateValue function.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24363 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by home-bradee.

        <rdar://problem/5336372>
        Icon database uses too much memory
        
        XRaying Safari startup memory consumption revealed that icon database is eating quite
        a bit of RAM if Icon.db is large (which it probably is if it has been in use for a while, 
        mine used for getting figures below was 2.6MB). 
        
        Note that the wins are less impressive with smaller Icon.db.
        
        This patch addresses three separate issues
        
        - SQLite fails to free the memory used by temporary tables. Icon database uses a temporary table
          on startup for pruning unused page urls. This wastes around 1MB. Addressed by rewriting
          pruning so it does not need a temporary table. The new method is also quite a bit faster speeding
          up Safari launch time by around 100ms
        - SQLite has it's own memory cache limited by default to 3MB. Icon database does not really need that much.
          Dropped the cache size to 300kB saving ~1MB on startup. 
          Smaller cache slows down startup by ~30ms (more than compensated by faster pruning above)
        - Don't populate m_pageURLToIconURLMap with all urls from database on startup, instead let it get populated
          when urls are accessed (user opens history menu for example). This shouldn't have any real performance impact 
          as the accesses are icon loads that need to hit the database anyway. This saves ~700kB.
          
        All in all with this Icon.db these changes reduce allocated memory by around 2.7MB on startup. Release build
        Safari RPRVT (empty start page) goes from 12.4MB to 10.4MB (TCMalloc pooling probably explaining why the win 
        looks bit smaller here).

        * loader/icon/IconDatabase.cpp:
        (WebCore::IconDatabase::IconDatabase):
        (WebCore::IconDatabase::open):
        (WebCore::IconDatabase::deleteAllPreparedStatements):
        (WebCore::IconDatabase::retainIconForPageURL):
        (WebCore::IconDatabase::releaseIconForPageURL):
        (WebCore::IconDatabase::establishIconIDForIconURL):
        (WebCore::IconDatabase::pruneUnretainedIconsOnStartup):
        * loader/icon/IconDatabase.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24364 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Maciej Stachowiak.

        <rdar://problem/5294691> Source of file is misrepresented if downloaded by typing in URL in Safari address bar

        * WebCoreSupport/WebFrameLoaderClient.h:
        * WebCoreSupport/WebFrameLoaderClient.mm:
        (WebFrameLoaderClient::download):
        Revised code to check the initial request's referrer before assuming it has a history to check.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24365 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Reviewed by Maciej Stachowiak.

        <rdar://problem/5294691> Source of file is misrepresented if downloaded by typing in URL in Safari address bar

        * loader/FrameLoaderClient.h:
        * loader/MainResourceLoader.cpp:        
        (WebCore::MainResourceLoader::continueAfterContentPolicy):
        Added an extra request parameter, initialRequest, to the download() method
        by passing up the resource handle's request.
        
        * platform/graphics/svg/SVGImageEmptyClients.h:
        (WebCore::SVGEmptyFrameLoaderClient::download):
        Added an extra parameter to the empty SVG download method.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24366 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests:

        Reviewed by Kevin McCulough.

        * http/tests/navigation/multiple-back-forward-entries-expected.txt:
        Updated results to match new behavior, which is correct (multiple
        history entries should not be created).

WebCore:

        Reviewed by Kevin McCulough.

        Fixed failing layout test.
        
        Renamed "FrameLoadTypeInternal" to "FrameLoadTypeRedirectWithLockedHistory".
        This is almost certainly not a correct name for the original intent
        of this load type, but it's a correct name for its current behavior.
        
        (WebCore::FrameLoader::updateHistoryForRedirectWithLockedHistory):
        When history is supposed to be locked, and no current history item
        exists, only add a new history item if you're the top-level frame.
        
        This rule, combined with the rule that setting iframe.src should not
        create a history item, is pretty hackish. On the other hand, it
        matches WinIE and doesn't cause any test regressions. So I'm OK with
        it as a short-term solution until the solution described in 
        <rdar://problem/5339292> can be implemented.



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24367 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Adding /VWebKit.LP64.exp to the project.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24368 268f45cc-cd09-0410-ab3c-d52691b4dbfc
        Build fix.

        * WebView/WebFrame.mm:
        (-[WebFrame _loadURL:referrer:intoChild:]):
        * WebView/WebFramePrivate.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24369 268f45cc-cd09-0410-ab3c-d52691b4dbfc
LayoutTests:

        Reviewed by Adam Roben.

        * fast/dom/Window/alert-undefined-expected.txt: Added.
        * fast/dom/Window/alert-undefined.html: Added.

WebCore:

        Reviewed by Adam Roben.

        Convert JS undefined to the empty string when calling alert, confirm, and prompt. 

        Test: fast/dom/Window/alert-undefined.html

        * page/DOMWindow.idl:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24371 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2007-07-17  Holger Hans Peter Freyther  <zecke@selfish.org>

        Reviewed by Maciej.

        Implement the callback responsible for handling HTTP headers. This
        callback gets called for every header.
        We will add these headers to our ResourceResponse and on the 'end-of-header'
        indicator we will update the ResourceResponse and dispatch it.

        This patch adds various set methods to ResourceResponse. This improves
        the readability of the headerCallback and avoids storing a CURL handle inside
        the ResourceResponse which would be needed to implement ResourceResponse::doUpdateResourceResponse

        Add a destructor for ResourceHandleManager which would free the resources and remove
        a unused variable.

        * platform/network/ResourceHandleInternal.h:
        (WebCore::ResourceHandleInternal::ResourceHandleInternal):
        * platform/network/ResourceResponse.cpp:
        (WebCore::ResourceResponse::setUrl):
        (WebCore::ResourceResponse::setMimeType):
        (WebCore::ResourceResponse::setExpectedContentLength):
        (WebCore::ResourceResponse::setTextEncodingName):
        (WebCore::ResourceResponse::setSuggestedFilename):
        * platform/network/ResourceResponse.h:
        * platform/network/curl/ResourceHandleCurl.cpp:
        (WebCore::ResourceHandleInternal::~ResourceHandleInternal):
        * platform/network/curl/ResourceHandleManager.cpp:
        (WebCore::ResourceHandleManager::~ResourceHandleManager):
        (WebCore::ResourceHandleManager::sharedInstance):
        (WebCore::headerCallback):
        * platform/network/curl/ResourceHandleManager.h:



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@24372 268f45cc-cd09-0410-ab3c-d52691b4dbfc