into the trash. If it's still in progress, cancel it. Dim the icon in any case.
Undim the icon if a download is moved back out of the trash (restarting still
has to happen manually).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@348 94f232f2-1747-11df-bad5-a5bfde151594
currently in progress anymore.
* Added feature to remove "missing" downloads, i.e. those for which no
corresponding file exists.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@346 94f232f2-1747-11df-bad5-a5bfde151594
output.
* Optimized download restoration at program start and moved it into download
window thread in order not to block app startup.
* Downloads which have been removed meanwhile, are displayed with dimmed icon,
and the option to Restart it is given.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@342 94f232f2-1747-11df-bad5-a5bfde151594
* Allow to specify the downloads folder in the General settings page.
* Added necessary wiring.
* The listener notification was not synchronous anymore because of mixed
up default function params in BWebPage.
* Added temporary debug output to WebDownloadPrivate.cpp... the restarting
downloads code path needs testing yet.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@341 94f232f2-1747-11df-bad5-a5bfde151594
* Probably fixed a race condition on program launch. If you started typing
into the URL field really fast, the static instance in
BrowsingHistory::DefaultInstance() could be created by two threads, which
may be responsible for the "recursive init" exception that GCC throws in
this situation. It's not easy to trigger, maybe this was it.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@335 94f232f2-1747-11df-bad5-a5bfde151594
clutter there. I'm quite happy now, but one issue could be that the Go menu is
not stable: Any URL will always appear only once, somewhere in the hierarchy,
depending on when you last visited it. The BrowsingHistory could be changed,
though, feedback welcome.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@330 94f232f2-1747-11df-bad5-a5bfde151594
* Search for existing bookmarks recursively.
* Open all bookmarks at once, when the user clicks a bookmark folder in
the menu (thanks Axel). But do ask for confirmation if there are more
than ten bookmarks.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@318 94f232f2-1747-11df-bad5-a5bfde151594
WebPositive is moved into the Haiku repo.
* Convert the Bookmarks menu into a BNavMenu, make sure it updates to the
current folder contens each time it opens.
* Wire everything to complete the bookmark support. Managing bookmarks is
fairly nice by re-using Tracker. One can even put anything into the book
mark folder and WebPositive will launch the respective app if it doesn't
have a META:url attribute. The most immediate benefit is that clicking
sub-folders in the Bookmarks folder will also open that folder in Tracker.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@315 94f232f2-1747-11df-bad5-a5bfde151594
* Introduced BWebPage::RequestDownload() public API (expected to run
synchronous).
* Added necessary wiring for "Download this link" in context menus.
* Restarting downloads works in principle, although with some quirks.
(Sometimes it appears the "Desktop" is being downloaded...)
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@310 94f232f2-1747-11df-bad5-a5bfde151594
* When adding/removing tabs, process a fake mouse moved event to synchronize
with the new tab layout.
* Count the mouse clicks for the "double click into empty area opens new tab"
feature in such a way that clicks into tabs never count (closing a tab was
the first click before, the second would immediately open a new tab and
similar issues).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@309 94f232f2-1747-11df-bad5-a5bfde151594
same functionality as the global methods for managing cookies. This is only
enabled for the Haiku platform. Since the global cookie methods get a Document
pointer, I envision, the CookieJarClient could eventually be a member of
Document instances. It would then be passed upon WebCore::Page creation.
Still waiting on feedback from other WebKit developers on this one. This change
is more elegant than what the Qt port does, which is to use WebKit classes in
WebCore (layering violation). Right now, a single global instance of a
CookieJarClient can be assigned.
* Implemented CookieJarClientHaiku which uses a BNetworkCookieJar to forward
the requests. Eventually, the behaviour could be browser specific.
* Added all the necessary wiring to BrowserApplication to make the cookie jar
persistent.
* TODO: Actually parse cookies and handle at least the expiration date, but
other stuff like matching the domain of the cookie and the URL and "HTTP-only"
cookies seems important as well.
Even though I have confirmed that cookies are stored and restored correctly,
and also retrieved via the global cookie methods, I can see no change in browser
behaviour. For example enabling "Stay signed in" on googlemail.com does not work
in WebPositive, although BeZillaBrowser automatically logs in in a new session
when surfing to googlemail.com. No idea if this is even implemented with
cookies, although it seems like it should be.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@303 94f232f2-1747-11df-bad5-a5bfde151594
The 8 and 2 on the number pad would not work in the URL bar otherwise, since
those map to "B_UP_ARROW" and "B_DOWN_ARROW" as raw char.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@302 94f232f2-1747-11df-bad5-a5bfde151594
delete itself in the application thread, we cannot delete the BWebView before
this happens in the window thread. Now BWebPage is repsonsible for deleting
the view.
* Also make sure that there are not still loaders running on the frame. Since
the timer messages arrive in a different handler than the BWebPage handler,
the timer functions being called could operate on stale pointers. I am not
sure why WebCore doesn't make sure of this itself. Perhaps we are not supposed
to delete something directly, but via reference counting. Though I am not sure
what it would be, since WebCore::Page is not reference countable. Maybe the
frame... need to investigate. After all, there could be other timers in the
queue besides loading related ones.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@295 94f232f2-1747-11df-bad5-a5bfde151594
same base URL anymore, but simply uses a lower priority for every less recent
choice with the same base URL, and then sorts the result list after fetching.
Previously, you would only get one choice for a given base URL, and that one was
more likely a longer URL, since it was visited more recently than the start page
of the respective site.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@286 94f232f2-1747-11df-bad5-a5bfde151594
* Took FontSelectionView from Haiku Fonts preflet, but almost rewrote it to
adapt for WebPositive needs. It's now a BHandler, so that it can actually
receive messages itself. The Fonts version is a BView which is never attached,
and only receives messages, because the window forwards them. Implemented
option to use separate style menu.
* Provide font settings in the Settings window.
* Wired everything to make it work, although I am not sure standard font is
applied. It does work for the serif font, though. Maybe I ought to install
more fonts and check with simpler HTML.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@284 94f232f2-1747-11df-bad5-a5bfde151594
removed too, once WebPositive is moved into Haiku. SettingsMessage comes straight
from MediaPlayer. Should be moved into src/kits/shared eventually.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@278 94f232f2-1747-11df-bad5-a5bfde151594
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
- cmd+w now closes the active tab. If the tab is the only one remaining, the window is closed.
- cmd+shift+w closes the window, regardless of tab count.
Whitespace cleanups.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@167 94f232f2-1747-11df-bad5-a5bfde151594
window to update itself to the properties of a page when switching pages.
Resolves deadlock problem with BWebPage::CanGoInDirection(), which I've removed.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@162 94f232f2-1747-11df-bad5-a5bfde151594
app thread indeed, but the app thread may already be blocking on the window lock,
we we cannot wait for a synchronous reply from the app in the window thread.
Refactored the tab creation and reused it in the LauncherWindow constructor.
Added the ability to load a URL in the new tab right away.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@160 94f232f2-1747-11df-bad5-a5bfde151594
extended version of the LaunchBox version (added TrimIcon() method). Will go
away when/if the browser is moved into the Haiku source tree.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@159 94f232f2-1747-11df-bad5-a5bfde151594
* Actually set the target on the tab view, so that we change urls when switching
tabs.
* Move all New/Close items to the top-level, since I find it slightly too
awkward to reach them otherwise.
* Misc coding style fixes.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@157 94f232f2-1747-11df-bad5-a5bfde151594
style. (WebPage -> BWebPage). Documented what needs to go where in WebPage.h.
* Moved misplaced functionality from WebFrame to BWebPage (navigation).
* EditorClientHaiku takes a BWebPage pointer now, which brings a slight cleanup.
* Exposed WebFrame::isEditable() to EditorClientHaiku, so isEditable() can be
implemented.
* Added some asserts in FrameLoaderClientHaiku according to the Gtk port and
placed some debug output.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@150 94f232f2-1747-11df-bad5-a5bfde151594
* Improved wording for persistency checkbox.
* Added BTextView for displaying the info text.
* Focus password input on second runs with bad password.
* Enabled drawing updates for blocking windows.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@90 94f232f2-1747-11df-bad5-a5bfde151594
which then invokes the authenticationChallenge() hook.
* Implemented that hook in LauncherWindow by means of the AuthenticationPanel.
* Removed realm and method arguments to AuthenticationPanel::getAuthentication()
and replaced them by a simple "text" that is constructed in the
FrameLoaderClient based on the challenge details. It is not yet shown though.
* Made a tab -> spaces replace and added myself to the copyrights in some files.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@74 94f232f2-1747-11df-bad5-a5bfde151594
so that we can eventually restart downloads.
* Checks if a downloaded file already has a previous download and replaces it.
(Actually, this should take the path into account, not only URL.)
* Stores the URL as "META:url" attribute, as the good old NetPositive did.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@60 94f232f2-1747-11df-bad5-a5bfde151594
not persistent.
Resolved TODO in WebProcess about race condition when dispatching download
notifications. Just block until there is a reply. WebDownload pointers are
just used for extracting information at init time, and then later only as
cookie to match view and download. Although as soon as we want to cancel downloads,
refcounting may become necessary again.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@57 94f232f2-1747-11df-bad5-a5bfde151594
that the window is on that send the request to show it. Remember the size and
if it was showing across sessions.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@56 94f232f2-1747-11df-bad5-a5bfde151594
become BWebView.) Compared to the original port, the threading has been
completely redesigned such that all interaction with WebKit happens in the
application thread, as required by the PThread threading backend. This is
counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext
for each Page, such that drawing is performed in various app_server threads
asynchronously. WebViewWindow provides as a target for messages from within
WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual
hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
