<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/105749/">http://git.reviewboard.kde.org/r/105749/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 27th, 2012, 8:50 a.m., <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
<p>On July 27th, 2012, 2:25 p.m., <b>Dawit Alemayehu</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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.</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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. </pre>
<br />
<p>- Parker</p>
<br />
<p>On July 27th, 2012, 8:52 a.m., Dawit Alemayehu wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/media/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Dolphin, KDE Base Apps and David Faure.</div>
<div>By Dawit Alemayehu.</div>
<p style="color: grey;"><i>Updated July 27, 2012, 8:52 a.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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
</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>konqueror/src/konqcombo.cpp <span style="color: grey">(cdf840a)</span></li>
<li>konqueror/src/konqmainwindow.cpp <span style="color: grey">(081509e)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/105749/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Screenshots </h1>
<div>
<a href="http://git.reviewboard.kde.org/r/105749/s/645/"><img src="http://git.reviewboard.kde.org/media/uploaded/images/2012/07/27/old_popup_window_400x100.png" style="border: 1px black solid;" alt="before the change" /></a>
<a href="http://git.reviewboard.kde.org/r/105749/s/646/"><img src="http://git.reviewboard.kde.org/media/uploaded/images/2012/07/27/new_popup_window_400x100.png" style="border: 1px black solid;" alt="after the change" /></a>
</div>
</td>
</tr>
</table>
</div>
</body>
</html>