since we did not delete the BWebView directly, but in the application thread,
this was a race condition that would only crash sometimes (in _TabChanged(),
when we tried to attach user data to the current tab before switching it). This
should fix the last known (to me) crash.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@452 94f232f2-1747-11df-bad5-a5bfde151594
into the text view, so the user can continue typing from that choice, or modify
it. For example, one can type "dev.haiku-os.org", select a choice
"http://dev.haiku-os.org/ticket/1234" and then replace just the last chunk with
another ticket number and press enter.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@447 94f232f2-1747-11df-bad5-a5bfde151594
need to always enable the standard shortcut items in MenusBeginning(), if we
would otherwise enable them only asynchronously. Fixes Cut/Copy/Paste via
shortcuts.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@443 94f232f2-1747-11df-bad5-a5bfde151594
This needs to be asynchronous, as always. BrowserWindow asks when menus are
opened, but the result arrives so fast, that the user never sees invalid
items. The Cut/Copy/Paste items are now always enabled according to what's
currently really possible.
* Enable and disable the Back/Forward History menu items along with the buttons.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@436 94f232f2-1747-11df-bad5-a5bfde151594
* Added Cut/Copy/Paste items. Enabled status is updated when a text view has
focus, but not yet with the selection of the BWebView, when that has focus.
* Dispatch B_CUT/COPY/PASTE either to a focused BTextView or to the BWebView.
* Enable the Find next/previous items according to contents of the Find text
input.
* Refactored MenusBeginning() hook.
* Renamed Go menu to History.
* Added Back/Forward menu items to History menu, now the shortcuts are visible.
(Command key plus cursor left/right)
* Added Reload item to View menu, now that shortcut is visible too.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@435 94f232f2-1747-11df-bad5-a5bfde151594
* Split WebTabView into several files in a new sub-folder "tabview".
* Implemented scrolling the tab view left/right when there are more tabs than
fit into the view.
* Fixed graphic glitches in the TabContainerView when the window is resized,
the space behind the last tab was not managed properly.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@416 94f232f2-1747-11df-bad5-a5bfde151594
supposed to allow specifying whether the new window/page shall be activated
or not.
* In ContextMenuController, when creating a new page from a link, specify that
it shall not be activated.
* Handle the new flag in the WebKit layer.
-> "Open link in tab" from the context menu no longer selects the new tab, but
opens it "in the background".
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@414 94f232f2-1747-11df-bad5-a5bfde151594
to just the part that describes the modifier keys in general. What's left should
be exactly B_COMMAND_KEY. This fixes the workspace switching short-cut to trigger
page history navigation WebPositive.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@408 94f232f2-1747-11df-bad5-a5bfde151594
* Added a context menu to the URL input for integration with the system
clipboard when you want to use the mouse only.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@403 94f232f2-1747-11df-bad5-a5bfde151594
works with the BTextView.
* Factored out the URL text handling into a new class URLInputGroup, which is
used instead of a plain BTextControl, but currently works much the same way.
It's a BGroupView though and allows easy addition of other controls and items
into the URL text field.
* Moved baseURL() method into it's own file, since it's used from multiple
places now.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@402 94f232f2-1747-11df-bad5-a5bfde151594
all. Open a blank page if no pages have been created from the arguments passed
to the application.
* If no pages have been created yet, don't offset the last known window frame.
This fixes windows shifting over the screen from session to session.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@397 94f232f2-1747-11df-bad5-a5bfde151594
likely to introduce erros with spelling settings keys wrong somewhere.
* Introduced new setting for the behavior if tabs should show at all if only
one page is showing in a window. Defaults to on, i.e. the previous behavior.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@393 94f232f2-1747-11df-bad5-a5bfde151594
associated with a BWebView and restore the focus when the tab changes. This fixes
a number of annoying issues.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@391 94f232f2-1747-11df-bad5-a5bfde151594
into the about window.
* Give access to the about window from the browser windows.
* Renamed the "Show *" entries in the Window menu to just "*".
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@387 94f232f2-1747-11df-bad5-a5bfde151594
will be passed to CreateNewTab(), so that BrowserWindows can be created to
embed a view which already exists.
* Extended NewPageCreated() hook with the additional information that
BWebPage::createPage() already provides. It can be used to decide if new
windows shall be created instead of creating another tab for the new page.
* Reworked BrowserWindow constructor with regards to the "DoNotHaveToolbar"
policy. All views are always created, BLayoutItems are remembered for the
various groups and are being turned invisible depending on policy. This way
each BrowserWindow is fully valid and can be reconfigured easily during
runtime. (Settings could be exposed as well now.)
* Changed ChromeClientHaiku::createWindow() implementation to not disregard
the "window features" properties if only some of them are not set.
All this combined makes the Haiku User Guide translation page open a separate
window for editing the translations just like BeZillaBrowser. What does not
work (but apparently also not in BeZillaBrowser) is clicking another block and
having the editing window update to show that block instead. Don't know if this
is actually supposed to work that way, it just seems like it should.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@380 94f232f2-1747-11df-bad5-a5bfde151594
B_QUIT_REQUESTED, instead BWebWindow has a new hook and derived classes can
implement it.
* Some refactoring in BrowserWindow to move code from MessageReceived into
separate methods for easier debugging and cleaner code.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@378 94f232f2-1747-11df-bad5-a5bfde151594
* Ignore resize requests when the window has more than one tab at all.
* Make sure the new size is not larger than the screen and shift the window so
everything is visible.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@368 94f232f2-1747-11df-bad5-a5bfde151594
for any at-exit-cleanup. Moved the closing of the favicon database from
BWebSettings there, since I wasn't sure if closing the icon database happened
at the right time, or perhaps too late if it was done via global destructors.
* Temporarily disabled the native cookie support, as it only delays application
startup time right now. We are really using the cURL cookies at the moment
and they work just fine it seems.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@362 94f232f2-1747-11df-bad5-a5bfde151594
can be scaled down by an even factor will now be displayed better. Also enable
smooth scaling and use a better drawing mode. The net result is that icons will
be displayed between 14x14 and 18x18 with the best suitable scaling factor.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@358 94f232f2-1747-11df-bad5-a5bfde151594
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
