* 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
into Haiku. Added new file HashKeys.h which implements commonly used HashKey
classes. Additionally to the ones found in HashMap.h, it has a HashKeyString
class, which wraps a BString and provides the GetHashCode() method.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@477 94f232f2-1747-11df-bad5-a5bfde151594
was outside as well.
* Single tertiary click outside tabs opens new tab on mouse up.
* Reset fClickCount always when the click was inside a tab.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@474 94f232f2-1747-11df-bad5-a5bfde151594
Label and trailing label are only specified in the constructor or in Reset().
By using SetText(), we were modifying another part of the text, while we meant
to set the label. This fixes updates on node monitor messages.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@472 94f232f2-1747-11df-bad5-a5bfde151594
true, we need to recheck it in MouseUp(). This would fix the problem with the
middle mouse button click to close tabs if we didn't move closing to the mouse
up event, and it also fixes other situations, like clicking on one tab, moving
the mouse over another tab's close button, releasing the mouse and clicking
again without moving it inbetween.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@471 94f232f2-1747-11df-bad5-a5bfde151594
would be true, but the fLastMouseEventTab would have been reset when removing
the tab. Rather than fixing this problem, behave the same as Firefox and close
the tab on mouse up (when the mouse is still over the tab, which allows the
user a way back out). Avoids the above problem as a side effect.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@469 94f232f2-1747-11df-bad5-a5bfde151594
* Added necessary wiring in BWebSettings for proxy server configuration.
Actual proxy server usage untested, feedback welcome.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@468 94f232f2-1747-11df-bad5-a5bfde151594
* Icon view needs to update completely on resize.
-> Fixes graphics glitch when switching between icon and no icon.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@467 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
not really useful. Neither is claiming support for text/*. Added support for
image/svg+xml, since I don't think anything else would handle it as good as
WebPositive (which will do better once BView supports affine transformations).
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@462 94f232f2-1747-11df-bad5-a5bfde151594
SettingsWindow::_RevertSettings().
* Made all necessary refactoring in order to support _CanApplySettings().
* Adjust the Apply and Revert button enabled state whenever settings change.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@458 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
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
