It still needs a lot but this doesn't seem to break anything and it already is
making my browsing more productive. The hard-coding of Google will be fixed
when some proper search engine provider handling is added.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@557 94f232f2-1747-11df-bad5-a5bfde151594
* Make sure that the BWebView for which a notification is received still exists.
This affected only the title changed notification, for which this was already
checked, and the icon received notification, which could actually lead to
a crash if the tab was closed before receiving the notification.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@522 94f232f2-1747-11df-bad5-a5bfde151594
preferred app for text/x-source-code. For remote pages, it will save a temporary
file and open the editor with that.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@517 94f232f2-1747-11df-bad5-a5bfde151594
* Load new files into the current tab, if the URL of that tab is either empty
or the URL for new tabs, instead of always opening a new tab.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@511 94f232f2-1747-11df-bad5-a5bfde151594
* Unhide the interface when the user invokes CMD-L (Open location).
* Make sure the progress bar is really hidden, sometimes it would be
visible again after unhiding the rest of the interface.
* Added a setting for the auto-hiding the mouse pointer feature. It defaults
to true, since I think it's useful for an app where the pointer would
usually be in the way.
* Hide the mouse pointer in any case as soon as the user begins typing, also
hide potentially showing tool tips in that case.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@496 94f232f2-1747-11df-bad5-a5bfde151594
were intercepting mouse messages even if the window was not showing. Now
secondary clicks are intercepted in DownloadWindow and the target view is found,
which makes this much cheaper.
* Offset context menus by 2 pixels, so the mouse does not start directly over
an item.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@488 94f232f2-1747-11df-bad5-a5bfde151594
"show tabs if single page only" option.
* Fixed problems with showing tabs when opening new tabs while the interface
was hidden. Introduced a new flag which tracks the hidden state to make
this easier.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@486 94f232f2-1747-11df-bad5-a5bfde151594
mouse cursor will automatically hide if you don't move it, unless it's over the
interface. The interface will disappear after three seconds if the cursor is
not above it. It will re-appear when you touch the top of the screen with the
mouse. I find this the best solution, since the mouse is also used for
navigation in the page, and showing the interface based on some virtual area
of the interface would just get in the way.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@485 94f232f2-1747-11df-bad5-a5bfde151594
objects are used for session and persistent storage of credentials with the
appropriate locking. Passwords are stored on disk insecurely. If the user
uses the checkmark in the authentication window to remember the credentials,
the persistent storage will be used, otherwise the session storage. In another
words, even if not asked to remember the credentials, the same user/pass never
needs to be entered more than once per session, unlike before. WebCore already
contains a CredentialStorage class, but we don't use it. It could be used via
the CURL networking backend implementation, only the CF backend uses it at all.
Since we don't have a "keyring" OS level service, this solution was more
convenient for the time being.
Note all this has nothing to do with storage of form data entered by the user.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@478 94f232f2-1747-11df-bad5-a5bfde151594
meant CurrentWebView(). This also fixed the focus restoration, since it
remembered the current focus for the wrong web view when the user data was
already stored.
* Refactored _TabChanged() so that this code is now executed in the now
virtual SetCurrentWebView(), which makes the features also work for new tabs.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@466 94f232f2-1747-11df-bad5-a5bfde151594
used to it, but also when only one page is open and tabs are not displayed as
per the user settings, the favicon would then not be visible.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@465 94f232f2-1747-11df-bad5-a5bfde151594
* Refactored setting the page icon so it always goes through the new
BrowserWindow::_SetPageIcon().
* Don't replace the PageUserData in _TabChanged() if it already exists
(which would forget the favicon).
* Write the favicon to the Bookmark file. At the moment, it writes the
32x32 icon as upscaled version of the 16x16 icon. Color reduction makes
the icons look not so nice, since Haiku does not yet support PNG icons...
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@464 94f232f2-1747-11df-bad5-a5bfde151594
* Allow specifying a start and a search page in the Settings window.
* Separated the "New page" policy into "New window" and "New tab" policies.
For a new window, the user can chose to "Open start page", "Open search page"
and "Open blank page". The default changed to "Open start page" and the
default start page points to the "Welcome" readme. For new tabs, there is
an additional choice "Clone current page". The default stayed with opening
a blank page.
* Implemented the new page policies in BrowserWindow.
* Listen for changes of the new settings in BrowserWindow.
* Added the new settings keys and default values to SettingsKeys.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@456 94f232f2-1747-11df-bad5-a5bfde151594
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
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
leavengood