Summary: | Cookie list has invisible domain names | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Guido Winkelmann <guido-kdebugs> |
Component: | general | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | adawit, maksim |
Priority: | NOR | ||
Version: | 4.3.5 | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Screenshot that illustates the invisible hostnames bug
Another screenshot, showing that, at the bottom, some domainnames are visible again Empty domain name in cookie dialog |
Description
Guido Winkelmann
2010-03-09 14:34:03 UTC
Created attachment 41477 [details]
Screenshot that illustates the invisible hostnames bug
Created attachment 41478 [details]
Another screenshot, showing that, at the bottom, some domainnames are visible again
As far as I remember, the ookie list used to work properly in KDE 4.3.3. I will see how it looks like in 4.4.1 as soon as I get home today. No such problem is visible in 4.4.1 Created attachment 43827 [details]
Empty domain name in cookie dialog
I'm having a possibly related problem on 4.4.3. The invisible hostname occurs in that dialog that pops up when cookies from an unknown site are recieved (see attached screenshot). I've set up a decline policy in this dialog, and now this policy shows up in my cookie rules list.
Might this have to do with the fact that the server I recieved the cookies from was running on a non-standard port (8080, see screenshot)? That's - as far as I can tell - the only difference from the usual case.
I can confirm the port 8080 thing, at least. I think the original issue was resolved by these commits: http://lists.kde.org/?l=kde-commits&m=123802505118255&w=2 http://lists.kde.org/?l=kde-commits&m=125482684530582&w=2 And the second one, the one that fixes the tab in question, is in 4.4.0, but not in 4.3.5. The 8080 issue has to do with how kcookiejar handles these --- it actually turns it into 8080:localhost or whatever (not sure of the rationale), and the decoding code freaks out on that and returns an empty string. Marking this as duplicate bug# 151839 for the 8080 port issue. Everything else should be fixed as explained comment #7... *** This bug has been marked as a duplicate of bug 151839 *** |