Version: 3.4.91 (using KDE 3.4.91 (beta1, >= 20050910) Level "a" , SUSE 9.3 UNSUPPORTED) Compiler: gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) OS: Linux (i686) release 2.6.10 When "detaching" a Tab containing an HTML form, the query leading to this page is resubmitted and any edits of the form are lost without warning.
In version 3.5.1-2.3.fc3.kde there is now a warning dialog box in the simple case (user fills in form, then tries to detach). However, in more complex cases (form is the result of a POST (for example "Preview" in Slashdot)), contents is lost without warning: 1. Go to slashdot.org, click Submit story 2. Fill in rubbish into the story field ("The scoop"). (If you attempt to detach at this stage, you do get a warning, which is good). 3. Press Preview 4. Without doing any further change to the story, click detach: you lose your contents _without_ any warning! Apparently konqueror "re"fetches via GET the contents which it got via a POST in the first place. It appears to me that the root of the problem is that konqueror spawns a new process to handle detach, rather than opening the new windows in its current process. Other KDE applications, such as konsole, handle detach just fine. If you detach a session in konsole, it keeps its current state, rather than opening a new session.
Still broken in 3.5.2
Confirmed in 3.5 branch r575787 as described in comment #1
I can confirm that following the steps from comment #1, using KDE4.1.
I've mostly fixed this problem. What seems to happen is that konqueror doesn't warn you that the changes might be discarded when you got those changes via POST. It doesn't warn you either when you get those via GET either, though. The thing is that konqueror was reloading the page. If you do that and the data was sent via GET, then that's not much of a problem because reloading the page will send the GET information. ON the other hand, if those were sent via POST, realoding the url will loose that information. The solution is copying all the data khtml can provide about the page (POST,GET, buffer, etc). This way the page will end up 99.9% exactly as you got it before. There's still no warning about having a possibility of loosing changes, but that possibility now is very small (can you find a page where it still happens?). This has been fixed today in trunk and in 4.1 branch.
In 4.2.2, we now do get a warning when attempting to detach a page with edited form contents, which is good. However, it would still be preferable, if the the page contents could be just kept (and passed to the child process, if you absolutely have to create one...), rather than needing to be reloaded on detach. There are some situations, such as confirmations of online orders, where any unasked reload may cause trouble.
Alain, what you mention in comment 6 is already covered by bug 72800, so I think we can leave this bug report (which was mostly about the missing warning, as I understand it) as fixed. In general, you should better not reopen closed bug reports to report something new, but rather file a new report (if there's no report about it yet).