When the cookies.accept_policy option is set as 1, ELinks pops up an "Accept cookie?" dialog box for each Set-Cookie header it receives. The current implementation of this dialog box has a few weaknesses.
1. If the HTTP response is a redirection, then ELinks follows it before the user has selected whether to accept or reject the cookie. Thus, the request for the target will not carry any cookies that the redirection response attempted to set. 2. If the user opens an entire folder from the bookmark manager as a set of tabs, then the Set-Cookie headers of all those pages result in dialog boxes on top of the current tab; the user must then dismiss all of those dialog boxes before he can proceed reading the page. The user should be allowed to load other pages in inactive tabs and not be concerned with the cookies of each page until he actually wants to read it. 3. The user generally cannot know how soon the "Accept cookie?" dialog box will pop up after he has requested a resource via ELinks, especially if redirections or slow connections are involved. Thus, the dialog box can pop up when the user is just about to press Enter or Y or N or the localized equivalents; ELinks will then treat the keypress as a response to the dialog box, even though the user did not intend it that way. 4. If ELinks receives another Set-Cookie header before the user has dismissed the previous "Accept cookie?" dialog box, ELinks pops up another one right on top of it. This compounds problem 1 because ELinks will then take the accept/reject answers in LIFO order (so the wrong cookie may be left active), and problem 3 because the user is then very likely to be about to press one of the problematic keys. I think the following scheme would resolve these issues while hopefully not introducing too many new ones. (I'm not volunteering to implement it now; I'd certainly have to read up on BFU first.) * To solve problem 3: Try to guess whether the user might be expecting an "Accept cookie?" dialog box. If he isn't, don't display it right away; instead, light up a LED and wait for the user to press a specific key. Preferably, the character in the LED would be the same as the key the user needs to press. The heuristic could be pretty simple: if the last command given by the user (whether via -remote or with the keyboard) was to load or reload a resource, then he's expecting a cookie, otherwise not. For example, scrolling the page or switching to a different tab would reset the flag and prevent dialog boxes from popping up. * To solve problem 1: Attach a list of pending cookies to each document. Receiving a Set-Cookie header grows the list; getting "Accept" or "Reject" from the user shrinks it. Follow redirections only when the list becomes empty. Light up the cookie LED whenever there are pending cookies for a document displayed in any open tab. If any of those cookies are for the current tab, display the LED more prominently; perhaps as an uppercase letter. * To solve problem 4: In the "Accept cookie?" dialog box, show all pending cookies at the same time, rather than one by one. Let the user quickly accept or reject the whole set of pending cookies received from a given document. (ELinks should turn Set-Cookie headers into pending cookies only when it has received the entire head of the response; this way, there is no risk that undesirable cookies sneak on the list just before the user accepts it.) When the dialog box opens, the pending cookies for the document of the current tab should be initially selected. The dialog box could perhaps be merged with the cookie manager, although I am not sure that would be a good idea. * To solve problem 2: Allow the user to close the "Accept cookie?" dialog box without deciding whether to accept or reject the cookies. The LED would then remain lit, until the user either closes the associated tabs or returns to the dialog and deals with the cookies.
pgpmTfzaTiDiQ.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
