bug#18550: eww-history-browse may end up calling eww-restore-history in an arbitrary buffer

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Ivan Shmakov <ivan@siamics.net> writes:

> Shortly: go to *eww*, H, C-x 1, C-x b *foo* RET, C-x b RET, RET,
> – the EWW history entry will be rendered in *foo*, /not/ *eww*.
>
> As of 0ee10aff098b, eww-history-browse uses quit-window to leave
> the history buffer, switching to the “next” buffer – as per
> (buffer-list), – and calls eww-restore-history right there.
>
> While the user may generally be expected to use M-x eww-history
> (which makes the current *eww* buffer the “next” one), select an
> entry, and M-x eww-history-browse it, – it’s also possible for
> the user to switch buffers arbitrarily between the calls.  This
> way, quit-window may select a completely unrelated buffer, and
> eww-restore-history will then call (erase-buffer) for it.

Hm....

--------
(quit-window &optional KILL WINDOW)

Quit WINDOW and bury its buffer.
WINDOW must be a live window and defaults to the selected one.
With prefix argument KILL non-nil, kill the buffer instead of
burying it.

According to information stored in WINDOW's `quit-restore' window
parameter either (1) delete WINDOW and its frame, (2) delete
WINDOW, (3) restore the buffer previously displayed in WINDOW,
or (4) make WINDOW display some other buffer than the present
one.  If non-nil, reset `quit-restore' parameter to nil.
--------

So I guess eww should set up the `quit-restore' thing properly.  I'll
have a peek.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no