when beginning to type something in the URL text field and the autocompletion
invoked the BrowsingHistory for the first time.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@270 94f232f2-1747-11df-bad5-a5bfde151594
choices is to find the "base url" (I am taking the string between :// and the
next /) and avoid adding any more urls with the same base URL. Seems to work
reasonably well. If anyone has any smarter ideas, please speak up! :-)
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@269 94f232f2-1747-11df-bad5-a5bfde151594
regards to eating the B_RETURN key before we can dispatch in BrowserWindow. So
autocompletion for URLs basically works. What's missing is:
* Much better grouping of matches.
* Fix the delay when the BrowsingHistory is first accessed (lazy loads itself
from disk just then, ought to do it in the application thread after startup,
which probably makes it unnoticable before the user starts typing a URL).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@268 94f232f2-1747-11df-bad5-a5bfde151594
permission from Oliver) and applied Haiku coding style. The base classes have
been named such that they could become official Haiku API in the future.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@266 94f232f2-1747-11df-bad5-a5bfde151594
NAVIGATION_REQUESTED notification again from the FrameLoaderClient, this way
we can try to fetch the icon even earlier.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@259 94f232f2-1747-11df-bad5-a5bfde151594
necessary. The only usable effect as of yet is that favicons arrive at the
BrowserWindow. Favicons are stored in a database and are not fetched when they
alreary exist. The application is expected to try and fetch an icon for a given
url. This is currently done in BWebWindow when the URL for loading has been
initiated. Otherwise it fetches the URL upon the new ICON_RECEIVED notification
from the FrameLoaderClientHaiku. In any case it ends up at BWebWindow::IconReceived(),
so derived classes don't have to worry about the difference. In any case, via
BWebSettings, icons can also be fetched manually, like for the forthcomming
autocompletion text control.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@257 94f232f2-1747-11df-bad5-a5bfde151594
it so much, since it somehow looks alien for no /really/ good reason. Maybe
I'll integrate this option into the settings, when I get to those.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@253 94f232f2-1747-11df-bad5-a5bfde151594
open a new file or url, check if there is already a window open on the current
workspace, and if so, open a new tab in that window and bring it to front.
ArgReceived() now reuses RefsReceived(), which has been extended to handle
"url" string fields in the message, since ArgReceived() may also be asked to
open urls and not only local files. The LOAD_AT_STARTING mechanism, which
turned out to be broken for multiple args anyway, could be replaced, since
RefsReceived() already buffers the message when it has been called earlier
then ReadyToRun().
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@244 94f232f2-1747-11df-bad5-a5bfde151594
gone when a BWebDownload wanted to use it. Now the class is more self-sufficient.
One example of the problem was clicking a link that opens a blank page, then
closing that page while the download was still loading. 1) The download finished
notification never arrived and 2) clicking to cancel the download would crash
after the download finished, since really it had already selfdestructed...
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@240 94f232f2-1747-11df-bad5-a5bfde151594
Original commit message of r238:
Split up WebPositive from HaikuLauncher. HaikuLauncher is back to it's simple
self. WebPositive uses a new WebPositive folder in config/settings. Otherwise,
everything should be as before. LauncherWindow and LauncherApp have been renamed
and cleaned up for the Haiku coding style.
Edit history with this rename commit to preserve history as we will git-filter --subdirectory-filter the WebPositive directory. The HaikuLauncher directory was renamed to WebPositive trough the past history with git-filter.
otherwise we may display the login panel above an unrelated page. Tested by
clicking Login on dev.haiku-os.org and Cmd-T to open a new tab before the
login panel shows. Works.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@237 94f232f2-1747-11df-bad5-a5bfde151594
buttons only available when there is more than one tab. This gives a more
consistent interface and doesn't hide features, most importantly the "Add tab"
button. For users that wish the most minimalistic UI, this behavior could
later be configurable (along with opening new windows versus new tabs).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@233 94f232f2-1747-11df-bad5-a5bfde151594
* Catch B_RETURN key down messages, when the target is the URL text view.
Don't let the text view send a message, but react on B_RETURN only, in the
window, also letting the Go button flash for a bonus. This fixes unprovoked
(re-)loading of pages when the text control went out of focus and thought the
text had changed, sending GOTO_URL. This could happen when just grabbing the
scrollbar so that the text control looses focus. Also makes the m_loadedURL
string superfluous, which I added for the same purpose.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@232 94f232f2-1747-11df-bad5-a5bfde151594
added and works.
* Added "Open location" shortcut Cmd-L as in Firefox.
* Moved "Show downloads" shortcut to Cmd-J, again as in Firefox. It uses Cmd-D
for "Bookmark this page". Though I have no idea why we simply shouldn't use
Cmd-D for Downloads and Cmd-B for Bookmark this page.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@229 94f232f2-1747-11df-bad5-a5bfde151594
* Tabs are only visible when there are more than one.
* Tabs have close buttons.
* Much more flexible, adding scrolling and left/right buttons when there are
more tabs than room will be easy. Also drag&drop of tabs.
I've tested this quite a bit, hopefully there are no regressions.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@228 94f232f2-1747-11df-bad5-a5bfde151594
haiku-os.org and probably a few other things. Basically, we were creating
the new pages ourselves in dispatchDecidePolicyForNewWindowAction(), but
we were meant to implement dispatchCreatePage() instead. Now, what we do is
similar for the Qt port, only better (found a bug in Arora): When the user
clicked with the tertiary mouse button, we create the window ourselves, as
before, and otherwise always have WebCore create the page instead.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@218 94f232f2-1747-11df-bad5-a5bfde151594
field was added to the NEW_WINDOW_REQUESTED message, and not passed on to the
internal NEW_TAB message. Fixed this, and also added a check for the tertiary
mouse button for regular navigation actions. This means clicking links with
the middle mouse button opens in a background tab regard less if it would have
opened a new page when clicked with the primary button.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@199 94f232f2-1747-11df-bad5-a5bfde151594
* Fixed a bug where the "Remove Finished" button in the downloads window would
be wrongly disabled whenever a new download started.
* Implemented cancelling downloads.
* Prepared restarting downloads as far as the GUI goes. Need to research this
first how a download can be triggered independently from anything else in
WebCore...
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@196 94f232f2-1747-11df-bad5-a5bfde151594
showing immediately after they have been created, some pages don't set the
title either, so then the tab still would't show.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@193 94f232f2-1747-11df-bad5-a5bfde151594
be ChromeClientHaiku has been moved to BWebPage. WebView.h is now clean and
would be ready for the Haiku tree.
* BWebPage no longer invalidates the BWebView when a resize happens, WebCore
already takes care of that.
* BWebView draws a white area in Draw() when the offscreen view is not clean.
since no unnecessary invalidation happens, this doesn't result in any flicker
and basically only speeds up perceived loading speed, since the web page is
immediately white upon program launch.
* Since WebTabView does not draw a frame, it removes B_FULL_UPDATE_ON_RESIZE
and thereby completely avoids flickering upon window resize.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@190 94f232f2-1747-11df-bad5-a5bfde151594
WebFramePrivate to hide WebCore internals from the public API.
FrameLoadClientHaiku:
* Don't send load requested in policy decision method
dispatchDecidePolicyForNavigationAction(). Calling the policy function with
PolicyUse will already trigger the load correctly. Ignore the request when
we want to load it into a new window/frame instead.
* Subframes returned false in canHandleRequest(). This was what stopped stuff
being loaded into sub frames! Finally frames and iframes are working. Praise
Ingo's Debugger once more!
* Renamed LOAD_TRANSFERING to LOAD_COMMITED, since WebCore means that the loader
and policy stuff have come to the conclusion to finally load the URL. So that's
also the event which needs to update the URL text control.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@182 94f232f2-1747-11df-bad5-a5bfde151594
