This removes the sslcert_viewer entirely from the code. Where
possible I've also trimmed out of frontends any code I think
should not be present.
Frontends should check and remove any further references that I
have failed to catch.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
To position the page-info window we have to tunnel all the
way from the current scaffolding, via its top-level gui window,
through to the toolbar. In the toolbar we look up the URL bar
and then determine the screen coordinates of the scaffolding
via the top level widget GTK semantics.
Finally we place the page-info window 4 pixels down and right of
the bottom-left of the entry box, which should look nice.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order for GTK windows to be styled properly, in the context
we use them, the page-info windows need to be marked as popup
windows (typically used for transient popups such a menus, so
ideal for us).
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This makes the page info properly transient and causes it
to handle activity in the corewindow and outside itself
properly. This includes ensuring that actions outside
the window will close it, etc.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Instead of extracting information from the X509 certificate chain in
the fetcher the entire chain is propagated in Distinguished Encoding
Rules (DER) format.
This allows all the information contained in a certificate chain to be
retained which can subsequently be presented to the user
By doing this, we ensure the scrollbars update their thumbs
properly, otherwise they can lag behind the page shape somewhat.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
To correctly refocus the location box on tab switching we
need to not update the url of the tab when the scaffold updates
its global context.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Because the initial navigation process on new browser window
creation is somewhat complex, we need a small state machine in
the GTK UI to ensure that we handle the correct combination
of focussing needed to maintain selection through initial tab
opening.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
So that when we create a new tab we automatically focus the
location box, pass the flag into create, and honour it when it
comes back to us.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This gets rid of temp_open_background which was, frankly, a bit
of an eyesore. In addition it makes the open-in-new-tab context
menu action behave like Firefox's with respect to the user's preference
regarding whether or not to immediately focus new tabs.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This should enable keyboard support for the other core windows
such as cookies, global history and the hotlist.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order to let keypresses operate the local history window on
GTK3 we have to permit the drawing area to get focus so that
the keypresses actually make their way into the event loop in
the correct place.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
