Bug 123303 - Reloading resets modifications in URL field
Summary: Reloading resets modifications in URL field
Status: RESOLVED WORKSFORME
Alias: None
Product: konqueror
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-08 20:52 UTC by Maciej Pilichowski
Modified: 2011-06-13 07:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maciej Pilichowski 2006-03-08 20:52:26 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

Type in location box
www.amazon.com
immediately hit stop. Now reload. Url is gone.
Comment 1 Thiago Macieira 2006-03-11 11:13:47 UTC
I cannot reproduce: Konqueror 3.5.1 r512077. The URL stays in the Location box.
Comment 2 Maciej Pilichowski 2006-03-11 20:16:44 UTC
Maybe your internet connection is too fast. Try something abroad:
www.merlin.com.pl
and JUST after hitting enter /confirming/ hit stop /here the url stays/. And then hit refresh /url disappears/.

How can I check my konqueror revision?
Comment 3 Dirk Stoecker 2006-08-22 10:41:19 UTC
Works in KDE 3.5.4. I know this bug could be confirmed in previous versions so I close the bug.
Comment 4 Dirk Stoecker 2006-08-22 21:28:25 UTC
I don't believe it. After closing the bug it happened again. It's essential to have some really slow loading page, so abort can be clicked before first loading. Only after reload the URL is wrong. It is not taken from URL field, where it is still displayed, but from the current displayed page.

Testing with an illegal domain helps as DNS lookup can slow down the stuff long enough.
Comment 5 Dirk Stoecker 2006-08-22 21:43:54 UTC
A shorter description: When entering something in URL field, reloading resets any changes and reloads current page. This is very disturbing in these cases, where no loading had been done at all.

Either reloading should load the currently entered page always (I think this will bring another set of problems) or the current URL must be changed as soon as enter has been pressed and not later (now it seems to be after first outside reaction be it DNS or loaded page).
Comment 6 Maciej Pilichowski 2006-08-22 23:17:17 UTC
> current URL must be changed as soon as enter has been presse

This one. The principle of the least surprise -- or in other words, this way it is more intuitive. 

Case: you type
www.google.com
then
www.amazn.com
enter, stop, reload --> google. Now, you have to type the "last" addres again.
Comment 7 Jaime Torres 2008-05-02 22:36:42 UTC
What it does in kde4 trunk 20080430, where the tip of the reload button says "reload the page actually in screen" is:
I enter a url of a non existing web server, and before the dns says it does not exists, I click the stop button.
The URL field remains with the non existing web server, and when I click the reload button, it goes to the previous existing page.

As a possible improvement, I suggest to put another icon in the URL field when the page to be loaded is interrupted before the server is reached, such a broken K gear (or something like that).
Comment 8 George Goldberg 2008-05-04 16:00:07 UTC
Still present in trunk r803492 and 3.5.9.
Comment 9 FiNeX 2010-09-05 21:28:01 UTC
Same problem as bug #110430
Comment 10 David Faure 2010-10-04 18:33:32 UTC
The initial report sounds like something that could be fixed, since empty is never better than non-empty.

However I kind of disagree that comment #6 is a bug. Sometimes I type crap in the location bar and realize I didn't want to do that at all, and I just want to get back the URL from the current page. How would one do that, if not using reload? I admit it's a bit of a workaround though, so if someone can tell me 1) how the user would do that otherwise, and 2) how other browsers handle reload, I'm open to making a change.
Comment 11 Dawit Alemayehu 2011-06-13 07:19:24 UTC
The original bug report cannot be reproduced. The other tangential report as stated in comment #6 has another bug report. See bug# 110430.