Review Request: Prevent Konqueror's address bar from being hidden by default

[Thomas Lübking]

> On July 27, 2012, 8:50 a.m., David Faure wrote:
> > I like the idea, but why the non-editable combo? What happens when navigating, in that window? Doesn't the combo then start to be messed up (the code assuming that it is editable, has history items, has completion, etc.) ... especially history handling could create additional trouble.
> > 
> > I'm just not sure there is any point in preventing the user from typing another url there, like in any other konqueror window.
> 
> Dawit Alemayehu wrote:
>     I made the combo box non-editable only because both Chromium and Firefox do the same thing. IOW, I was simply copying them. In fact both of those browsers seem to change the address bar from a combobox to a staright line edit widget. Since I really do not have any objection or see any problem with letting the user edit the address bar, I can most definitely change the patch to allow it.
> 
> Parker Coates wrote:
>     My guess (and it's purely a guess) is that the intention is to prevent the user from entering a new URL manually, opening a new page in the "neutered" window, and then being frustrated that they don't have any of the normal toolbars, tabs, menus, etc. (I've actually seen this happen to a user.) Making the URL read-only effectively locks chromeless window to the current task and prevents the user from using it for general browsing.
> 
> David Faure wrote:
>     The user could still follow a link to google... :-) But yeah I see your point. Websites who open popups, usually limit the navigation available from the popup anyway.
>     
>     OK, I withdraw my request for the combo to be editable.
>     
>     Please verify that actual navigation in the popup window doesn't break stuff, and commit.
>     
>     Hehe the user could still make the bookmarks toolbar appear and navigate using that ... but ok that's convoluted. A more common case: clicking on the Home button, since it appears in the location toolbar? In your screenshot the toolbar has only the location bar, but what if the toolbar has more buttons - as it does by default, right?
> 
> Dawit Alemayehu wrote:
>     @Parker That actually makes sense. In fact they go out of their way to disable almost everything in the pop up window. Chromium even goes further and when you use the shortcut key to attempt to create a new tab, it intercepts it and creates the new tab in the window from which the pop was created. Firefox just simply ignores such attempts. What is curious to me however is that both of them allow you to navigate the web by clicking on links. They also allow you to navigate back and forward through the context menu.
>     
>     @David The toolbar having more buttons is not an issue because I clear it before adding back the combo box. So even if the user had added more actions to the location bar, they will be removed. However, I found out that I actually need to find a way to disable/hide/remove most of the actions that are part of the window's actionCollection. Otherwise, the user can simply use the context menu or the shortcut keys to create new tabs or show the menu bar. 
>     
>     I am still unsure how to verify this change does not break stuff. Things seem to work correctly in the main window from which the popup was launched and the popup window itself, but I guess I need to verify what happens to the navigation history of the pop up window. Does that need to be transmitted to the other browsers ?
> 
> Dawit Alemayehu wrote:
>     I of course meant to say to other windows not browsers...

Since the main concern seem to be protection against fishing, would it make sense to
a) make this size (compared to the desktop) dependent? (so that a "web-app" still looks like one while sth. that could be mistaken for a dialog has this level of protection)
b) do as said and remove toolbars etc. (to prevent navigation) but instead show a label that makes clear (besides the titlebar) that this is <h1>Konqueror - http://www.site.com</h1>


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105749/#review16512
-----------------------------------------------------------


On July 27, 2012, 8:52 a.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105749/
> -----------------------------------------------------------
> 
> (Updated July 27, 2012, 8:52 a.m.)
> 
> 
> Review request for Dolphin, KDE Base Apps and David Faure.
> 
> 
> Description
> -------
> 
> The attached patch attempts to resolve a security concern in Konqueror when browsing the web. The concern results from a website, through the use of the javascript window.open API, requests the creation of a new window (pop up window) with all its toolbars disabled. When Konqueror gets such requests it simply disables all toolbars in the main window including the one that contains the address line edit widget. This is a problem because it makes it possible for sites to spoof the user into providing personal information by mimicking native input dialog such as the password dialog.
> 
> As such this patch attempts to solve the problem in the same manner it seems to be addressed in other major browsers such as Firefox and Chromium. Namely, Konqueror will no longer hide the toolbar containing the address line edit widget by default. The user must explicitly override the default settings by adding the following configuration option to konquerorrc:
> 
> [DisableWindowOpenFeatures]
> LocationBar=false
>     
> 
> 
> Diffs
> -----
> 
>   konqueror/src/konqcombo.cpp cdf840a 
>   konqueror/src/konqmainwindow.cpp 081509e 
> 
> Diff: http://git.reviewboard.kde.org/r/105749/diff/
> 
> 
> Testing
> -------
> 
> 
> Screenshots
> -----------
> 
> before the change
>   http://git.reviewboard.kde.org/r/105749/s/645/
> after the change
>   http://git.reviewboard.kde.org/r/105749/s/646/
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120727/e5fbad38/attachment.htm>