GNU bug report logs - #69232
30.0.50; [PATCH] EWW history navigation gets caught in a loop

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 69232 in the body.
You can then email your comments to 69232 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [PATCH] EWW history navigation gets caught in a loop
Date: Sat, 17 Feb 2024 20:59:57 -0800

[Message part 1 (text/plain, inline)]

If you navigate back in EWW history, and then forward, you can never hit 
the "end": it keeps adding duplicate history elements, even though 
you're not visiting any new pages. To see this in action, start from 
`emacs -Q`, then:

M-x eww RET fsf.org RET
M-x eww RET gnu.org RET
H    ;; Notice that there's one item in the history: the FSF page[1]
q    ;; Close history window
l    ;; Go back one in the history to the FSF page
H    ;; Notice that there are two items in the history
r    ;; Go forward one, back at the GNU page
r    ;; Go forward again, now at the FSF page(?!)
r    ;; Ditto, now at the GNU page
r    ;; Repeat ad infinitum
H    ;; Now there are many entries, alternating between GNU and FSF

Attached is a patch that fixes this. Now, 'eww-save-history' will update 
the history entry in-place when viewing a historical page, and 
'eww-back-url' / 'eww-forward-url' take that into account. I also fixed 
the predicates for when the back/forward menu items were enabled.

I think this is just a straightforward bug fix, so I didn't add a NEWS 
entry. I could add one though if it seems worthwhile.

[1] EWW doesn't immediately add pages to the history when you navigate 
to them. Maybe it should, but that can be addressed another day.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #8 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50;
 [PATCH] EWW history navigation gets caught in a loop
Date: Mon, 19 Feb 2024 14:12:07 +0200

> Date: Sat, 17 Feb 2024 20:59:57 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> If you navigate back in EWW history, and then forward, you can never hit 
> the "end": it keeps adding duplicate history elements, even though 
> you're not visiting any new pages. To see this in action, start from 
> `emacs -Q`, then:
> 
> M-x eww RET fsf.org RET
> M-x eww RET gnu.org RET
> H    ;; Notice that there's one item in the history: the FSF page[1]
> q    ;; Close history window
> l    ;; Go back one in the history to the FSF page
> H    ;; Notice that there are two items in the history
> r    ;; Go forward one, back at the GNU page
> r    ;; Go forward again, now at the FSF page(?!)
> r    ;; Ditto, now at the GNU page
> r    ;; Repeat ad infinitum
> H    ;; Now there are many entries, alternating between GNU and FSF
> 
> Attached is a patch that fixes this. Now, 'eww-save-history' will update 
> the history entry in-place when viewing a historical page, and 
> 'eww-back-url' / 'eww-forward-url' take that into account. I also fixed 
> the predicates for when the back/forward menu items were enabled.
> 
> I think this is just a straightforward bug fix, so I didn't add a NEWS 
> entry. I could add one though if it seems worthwhile.

I'm not sure this is a bug fix, and I think this behavior change does
need a NEWS entry.

And have sure you are that no one will want the current behavior?

Message #11 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Mon, 19 Feb 2024 10:55:49 -0800

[Message part 1 (text/plain, inline)]

On 2/19/2024 4:12 AM, Eli Zaretskii wrote:
> I'm not sure this is a bug fix, and I think this behavior change does
> need a NEWS entry.

Ok, I added one.

> And have sure you are that no one will want the current behavior?

Well, I suppose I can't prove that there's no one who likes the current 
behavior. I'd be pretty surprised though, since I've never seen a 
browser that manages back/forward navigation like this.

In *theory*, a person might be able to (ab)use this to track changes to 
a given page across refreshes, but that doesn't work consistently, since 
EWW doesn't always add a new history entry upon reloading. Given that 
you have to jump through some hoops to trigger this behavior (for 
example, this doesn't work if you're at a new page not in 'eww-history' 
yet), I doubt anyone has noticed that this is possible. On the off 
chance that someone wants a feature like that, I think we could do it in 
a better way, anyway.

If you're still concerned that someone might prefer the current 
behavior, I could announce the change to emacs-devel after (or before) 
it merges in order to give people an opportunity to speak up.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #14 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Mon, 19 Feb 2024 21:17:24 +0200

> Date: Mon, 19 Feb 2024 10:55:49 -0800
> Cc: 69232 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> If you're still concerned that someone might prefer the current 
> behavior, I could announce the change to emacs-devel after (or before) 
> it merges in order to give people an opportunity to speak up.

Maybe announce it now, so that in a week or two, when it's time to
install, we could learn whether this change would bother someone.

Thanks.

Message #17 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 22 Feb 2024 15:22:26 +0200

> Date: Mon, 19 Feb 2024 10:55:49 -0800
> Cc: 69232 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 2/19/2024 4:12 AM, Eli Zaretskii wrote:
> > I'm not sure this is a bug fix, and I think this behavior change does
> > need a NEWS entry.
> 
> Ok, I added one.

Thanks, but I'm afraid it's somewhat confusing:

> +*** History navigation in EWW now works like other browsers.
> +Previously, when navigating back and forward through page history in
> +EWW, new history entries could get added to the history list.  Now, when
> +navigating through history, EWW preserves the history list and only
> +displays the relevant history entry.

This doesn't really explain the nature of the change in behavior.
AFAIU, the previous behavior was that going back in browsing history
could add the old entries to the history instead of removing them; now
going back will _never_ add entries to the history.  Isn't that so?

Message #20 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 22 Feb 2024 09:18:47 -0800

[Message part 1 (text/plain, inline)]

On 2/22/2024 5:22 AM, Eli Zaretskii wrote:
>> Date: Mon, 19 Feb 2024 10:55:49 -0800
>> Cc: 69232 <at> debbugs.gnu.org
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> On 2/19/2024 4:12 AM, Eli Zaretskii wrote:
>>> I'm not sure this is a bug fix, and I think this behavior change does
>>> need a NEWS entry.
>>
>> Ok, I added one.
> 
> Thanks, but I'm afraid it's somewhat confusing:
> 
>> +*** History navigation in EWW now works like other browsers.
>> +Previously, when navigating back and forward through page history in
>> +EWW, new history entries could get added to the history list.  Now, when
>> +navigating through history, EWW preserves the history list and only
>> +displays the relevant history entry.
> 
> This doesn't really explain the nature of the change in behavior.
> AFAIU, the previous behavior was that going back in browsing history
> could add the old entries to the history instead of removing them; now
> going back will _never_ add entries to the history.  Isn't that so?

In other browsers, you only add new entries to the back/forward history 
when you go to a totally new page (e.g. by clicking a link). If you just 
go back or forward, you should only change your position in the 
already-existing history. That's (roughly) what EWW does with the patch, 
with the exception that a new page doesn't go into the history immediately.

Previously, every time you went back or forward, it added entries to the 
end of the history list.

How does this look?

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #23 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 22 Feb 2024 21:04:35 +0200

> Date: Thu, 22 Feb 2024 09:18:47 -0800
> Cc: 69232 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 2/22/2024 5:22 AM, Eli Zaretskii wrote:
> >> Date: Mon, 19 Feb 2024 10:55:49 -0800
> >> Cc: 69232 <at> debbugs.gnu.org
> >> From: Jim Porter <jporterbugs <at> gmail.com>
> >>
> >> On 2/19/2024 4:12 AM, Eli Zaretskii wrote:
> >>> I'm not sure this is a bug fix, and I think this behavior change does
> >>> need a NEWS entry.
> >>
> >> Ok, I added one.
> > 
> > Thanks, but I'm afraid it's somewhat confusing:
> > 
> >> +*** History navigation in EWW now works like other browsers.
> >> +Previously, when navigating back and forward through page history in
> >> +EWW, new history entries could get added to the history list.  Now, when
> >> +navigating through history, EWW preserves the history list and only
> >> +displays the relevant history entry.
> > 
> > This doesn't really explain the nature of the change in behavior.
> > AFAIU, the previous behavior was that going back in browsing history
> > could add the old entries to the history instead of removing them; now
> > going back will _never_ add entries to the history.  Isn't that so?
> 
> In other browsers, you only add new entries to the back/forward history 
> when you go to a totally new page (e.g. by clicking a link). If you just 
> go back or forward, you should only change your position in the 
> already-existing history. That's (roughly) what EWW does with the patch, 
> with the exception that a new page doesn't go into the history immediately.
> 
> Previously, every time you went back or forward, it added entries to the 
> end of the history list.
> 
> How does this look?

It is IMO still not clear enough about the behavior change.  It looks
like you are describing what the old implementation did and the new
one will do, instead of describing the behavior as it the user will
see it.  Can you instead describe the change in terms of user-facing
behavior?

Message #26 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 22 Feb 2024 22:13:59 +0200

> Date: Thu, 22 Feb 2024 12:10:36 -0800
> Cc: 69232 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 2/22/2024 11:04 AM, Eli Zaretskii wrote:
> > It is IMO still not clear enough about the behavior change.  It looks
> > like you are describing what the old implementation did and the new
> > one will do, instead of describing the behavior as it the user will
> > see it.  Can you instead describe the change in terms of user-facing
> > behavior?
> 
> What about this? It mentions the (IMO) buggy behavior and how the new 
> implementation prevents that.

Much better, thanks.

Message #29 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 22 Feb 2024 12:10:36 -0800

[Message part 1 (text/plain, inline)]

On 2/22/2024 11:04 AM, Eli Zaretskii wrote:
> It is IMO still not clear enough about the behavior change.  It looks
> like you are describing what the old implementation did and the new
> one will do, instead of describing the behavior as it the user will
> see it.  Can you instead describe the change in terms of user-facing
> behavior?

What about this? It mentions the (IMO) buggy behavior and how the new 
implementation prevents that.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #32 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Sat, 24 Feb 2024 19:45:49 +0530

Jim Porter wrote:

> From 0f2528482527262ff59153595d7a3f10517153ca Mon Sep 17 00:00:00 2001
> From: Jim Porter <jporterbugs <at> gmail.com>
> Date: Sat, 17 Feb 2024 20:49:15 -0800
> Subject: [PATCH] When navigating through history in EWW, don't keep adding to
>  'eww-history'
>
> This resolves an issue where navigating back and then forward kept
> adding new history entries so you could never hit the "end" (bug#69232).
>
> * lisp/net/eww.el (eww-history-position): Add docstring.
> (eww-mode-map, eww-context-menu): Use correct predicates for when to
> enable back/forward.
> (eww-save-history): Save history entry in its original place when
> viewing a historical page.
> (eww-back-url): Set 'eww-history-position' based on the result of
> 'eww-save-history'.
> (eww-forward-url): Set 'eww-history-position' directly, since
> 'eww-save-history' no longer adds a new entry in this case.
>
> * etc/NEWS: Announce this change.
> ---
>  etc/NEWS        |  8 ++++++++
>  lisp/net/eww.el | 39 ++++++++++++++++++++++++++++-----------
>  2 files changed, 36 insertions(+), 11 deletions(-)

One possible problem with this patch, I realize now, is that if you
navigate backward ('l') and then visit another link there, the new page
is added to the very end of history rather than the immediate next
position. This would be confusing if you, then, navigate back and find
that it's not the page from which you followed the link. Perhaps the
original code was a hack around this?

--
James

Message #35 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: James Thomas <jimjoe <at> gmx.net>
Cc: jporterbugs <at> gmail.com, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50;
 [PATCH] EWW history navigation gets caught in a loop
Date: Sat, 24 Feb 2024 16:20:55 +0200

> Cc: 69232 <at> debbugs.gnu.org
> Date: Sat, 24 Feb 2024 19:45:49 +0530
> From:  James Thomas via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> One possible problem with this patch, I realize now, is that if you
> navigate backward ('l') and then visit another link there, the new page
> is added to the very end of history rather than the immediate next
> position. This would be confusing if you, then, navigate back and find
> that it's not the page from which you followed the link. Perhaps the
> original code was a hack around this?

The only reasonable alternative is to throw away all the history after
'l', which I don't think is better.

What do other browsers do in this situation?

Message #38 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, James Thomas <jimjoe <at> gmx.net>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Sat, 24 Feb 2024 14:29:21 -0800

On 2/24/2024 6:20 AM, Eli Zaretskii wrote:
>> Cc: 69232 <at> debbugs.gnu.org
>> Date: Sat, 24 Feb 2024 19:45:49 +0530
>> From:  James Thomas via "Bug reports for GNU Emacs,
>>   the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> One possible problem with this patch, I realize now, is that if you
>> navigate backward ('l') and then visit another link there, the new page
>> is added to the very end of history rather than the immediate next
>> position. This would be confusing if you, then, navigate back and find
>> that it's not the page from which you followed the link. Perhaps the
>> original code was a hack around this?

I intentionally chose not to address this in my patch (though perhaps 
that's not the right call).

> The only reasonable alternative is to throw away all the history after
> 'l', which I don't think is better.
> 
> What do other browsers do in this situation?

They throw away any history after the page you clicked the link on 
(which I think is what you mean by the above).

Another option might be, "If you're at a historical page and you click a 
link, add that page as a duplicate to the end of the history." That 
would partially restore the old behavior, but only in this case where 
things might otherwise be confusing.

We could also add a user option to select between these behaviors, since 
the former is the de facto standard for browsers.

(I think the real fix would be something like a history *tree*, but 
that's probably quite a bit more work.)

Message #41 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jporterbugs <at> gmail.com, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Sun, 25 Feb 2024 04:04:13 +0530

Eli Zaretskii wrote:

> The only reasonable alternative is to throw away all the history after
> 'l', which I don't think is better.
>
> What do other browsers do in this situation?

Exactly that. Firefox, Chrome etc. for e.g.

--
James

Message #44 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Sun, 25 Feb 2024 06:20:15 +0530

Jim Porter wrote:

> Another option might be, "If you're at a historical page and you click
> a link, add that page as a duplicate to the end of the history." That
> would partially restore the old behavior, but only in this case where
> things might otherwise be confusing.

Just putting out a few ideas for refining this (in case it's opted for):

My personal preference would be for the entire history up to that point
be added (or be available), not just the source page of the link; so
because that might sometimes be too much, (adding to the end) only the
entire history up to the first occurrence of the source page.

--

Message #47 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: James Thomas <jimjoe <at> gmx.net>
Cc: jporterbugs <at> gmail.com, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Sun, 25 Feb 2024 07:57:38 +0200

> From: James Thomas <jimjoe <at> gmx.net>
> Cc: jporterbugs <at> gmail.com,  69232 <at> debbugs.gnu.org
> Date: Sun, 25 Feb 2024 04:04:13 +0530
> 
> Eli Zaretskii wrote:
> 
> > The only reasonable alternative is to throw away all the history after
> > 'l', which I don't think is better.
> >
> > What do other browsers do in this situation?
> 
> Exactly that. Firefox, Chrome etc. for e.g.

So maybe we should offer that as optional behavior?

Message #50 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, James Thomas <jimjoe <at> gmx.net>
Cc: 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Sun, 25 Feb 2024 11:40:39 -0800

On 2/24/2024 9:57 PM, Eli Zaretskii wrote:
>> From: James Thomas <jimjoe <at> gmx.net>
>> Cc: jporterbugs <at> gmail.com,  69232 <at> debbugs.gnu.org
>> Date: Sun, 25 Feb 2024 04:04:13 +0530
>>
>> Eli Zaretskii wrote:
>>
>>> The only reasonable alternative is to throw away all the history after
>>> 'l', which I don't think is better.
>>>
>>> What do other browsers do in this situation?
>>
>> Exactly that. Firefox, Chrome etc. for e.g.
> 
> So maybe we should offer that as optional behavior?

If anything, I think this should be the default, with some other options 
provided for people who don't want to lose any history. That way the 
default behavior is what people know.

How about this as an option for preserving history though: if you're at 
a historical page and you navigate to a link, open that link in a *new* 
buffer, copying over the history leading up to that link. That way, you 
have two separate history timelines and nothing ever gets lost or munged.

Message #53 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Sun, 25 Feb 2024 21:49:07 +0200

> Date: Sun, 25 Feb 2024 11:40:39 -0800
> Cc: 69232 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 2/24/2024 9:57 PM, Eli Zaretskii wrote:
> >> From: James Thomas <jimjoe <at> gmx.net>
> >> Cc: jporterbugs <at> gmail.com,  69232 <at> debbugs.gnu.org
> >> Date: Sun, 25 Feb 2024 04:04:13 +0530
> >>
> >> Eli Zaretskii wrote:
> >>
> >>> The only reasonable alternative is to throw away all the history after
> >>> 'l', which I don't think is better.
> >>>
> >>> What do other browsers do in this situation?
> >>
> >> Exactly that. Firefox, Chrome etc. for e.g.
> > 
> > So maybe we should offer that as optional behavior?
> 
> If anything, I think this should be the default, with some other options 
> provided for people who don't want to lose any history. That way the 
> default behavior is what people know.

I don't think I mind.

> How about this as an option for preserving history though: if you're at 
> a historical page and you navigate to a link, open that link in a *new* 
> buffer, copying over the history leading up to that link. That way, you 
> have two separate history timelines and nothing ever gets lost or munged.

Sounds too complicated, and two backward-incompatible changes instead
of just one.  My recommendation is not to over-engineer this.

Message #56 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Sun, 25 Feb 2024 14:41:26 -0800

On 2/25/2024 11:49 AM, Eli Zaretskii wrote:
>> If anything, I think this should be the default, with some other options
>> provided for people who don't want to lose any history. That way the
>> default behavior is what people know.
> 
> I don't think I mind.

Thanks. Even if there were multiple options, this is probably what I'd 
choose, if only out of habit.

>> How about this as an option for preserving history though: if you're at
>> a historical page and you navigate to a link, open that link in a *new*
>> buffer, copying over the history leading up to that link. That way, you
>> have two separate history timelines and nothing ever gets lost or munged.
> 
> Sounds too complicated, and two backward-incompatible changes instead
> of just one.  My recommendation is not to over-engineer this.

I'm ok with implementing any combination of options here to make people 
happy (within reason; let's keep the number of possibilities to a few). 
If that means just making EWW work like other browsers, for better or 
worse, that's ok too. We can always revisit the decision to add more 
options later.

In any case, I'm going to look into writing some regression tests for 
this code so that we can be sure it works correctly.

Message #59 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Wed, 28 Feb 2024 15:39:16 -0800

[Message part 1 (text/plain, inline)]

On 2/25/2024 2:41 PM, Jim Porter wrote:
> On 2/25/2024 11:49 AM, Eli Zaretskii wrote:
>>> If anything, I think this should be the default, with some other options
>>> provided for people who don't want to lose any history. That way the
>>> default behavior is what people know.
>>
>> I don't think I mind.
> 
> Thanks. Even if there were multiple options, this is probably what I'd 
> choose, if only out of habit.

Here's a patch that deletes "future history" in the case we'd previously 
discussed. I also added some regression tests for this. I think this all 
works correctly, but it's probably worth some manual testing over a few 
days just to be on the safe side.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #62 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 29 Feb 2024 09:03:33 +0200

> Date: Wed, 28 Feb 2024 15:39:16 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
> 
> On 2/25/2024 2:41 PM, Jim Porter wrote:
> > On 2/25/2024 11:49 AM, Eli Zaretskii wrote:
> >>> If anything, I think this should be the default, with some other options
> >>> provided for people who don't want to lose any history. That way the
> >>> default behavior is what people know.
> >>
> >> I don't think I mind.
> > 
> > Thanks. Even if there were multiple options, this is probably what I'd 
> > choose, if only out of habit.
> 
> Here's a patch that deletes "future history" in the case we'd previously 
> discussed. I also added some regression tests for this. I think this all 
> works correctly, but it's probably worth some manual testing over a few 
> days just to be on the safe side.

Thanks, but I thought we were talking about some user option, since at
least some people said they don't like what other browsers do?

> +(defun eww-save-history (&optional clear-future)
> +  "Save the current page's data to the history.
> +If the current page is a historial one loaded from
> +`eww-history' (e.g. by calling `eww-back-url'), this will update the
> +page's entry in `eww-history' and return nil.  Otherwise, add a new
> +entry to `eww-history' and return t.
> +
> +If CLEAR-FUTURE is non-nil, clear any future history elements from
> +`eww-history'."

This should probably explain what it means by "future history
elements".

Thanks.

Message #65 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 29 Feb 2024 09:32:09 -0800

On 2/28/2024 11:03 PM, Eli Zaretskii wrote:
> Thanks, but I thought we were talking about some user option, since at
> least some people said they don't like what other browsers do?

I'll wait to see if James has anything to say about this patch, but my 
understanding was that his problem was that the first version of my 
patch *didn't* work like other browsers, and he wanted something closer 
to that.

I don't mind adding an option though, once we have an idea of what 
options we'd want to support. One simple way might be to add some option 
like 'eww-history-replacement-function' (name suggestions welcome), 
which runs any time the user is at a historical page and navigates to a 
new one. This would default to the hypothetical function 
'eww-history-delete-future' and do what my latest patch does. Then users 
can write their own functions to modify the behavior.

It would also be nice to have an option like the Emacs 29 behavior, but 
with the bug in my original report still fixed. I'm not sure exactly the 
best implementation for this yet though...

Message #68 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Fri, 01 Mar 2024 05:00:34 +0530

Jim Porter wrote:

> On 2/28/2024 11:03 PM, Eli Zaretskii wrote:
>> Thanks, but I thought we were talking about some user option, since at
>> least some people said they don't like what other browsers do?
>
> I'll wait to see if James has anything to say about this patch, but my
> understanding was that his problem was that the first version of my
> patch *didn't* work like other browsers, and he wanted something
> closer to that.

The current patch is much better for me personally: 'l' and 'r' now do
what they're supposed to do. But my ideal (short of any advanced 'tree'
mechanism), as I originally stated, would've been to _insert_ (rather
than _replace_) the new history at the position in the current history
where it's created (but I see that there's no SOP for that in (info
"(elisp) Minibuffer History"), and that there could be performance
implications).

> I don't mind adding an option though, once we have an idea of what
> options we'd want to support. One simple way might be to add some
> option like 'eww-history-replacement-function' (name suggestions
> welcome), which runs any time the user is at a historical page and
> navigates to a new one. This would default to the hypothetical
> function 'eww-history-delete-future' and do what my latest patch does.
> Then users can write their own functions to modify the behavior.

Why not simply make 'eww-save-history' customizable?

> It would also be nice to have an option like the Emacs 29 behavior,
> but with the bug in my original report still fixed. I'm not sure
> exactly the best implementation for this yet though...

TBH I don't think anyone would have been (ab)using it effectively
because each 'l' or 'r' made things more complicated; but the advantage
that *all* of history was available with 'H'.

(I'm using this patch and will let you know if I see anything amiss)

Regards,
James

Message #71 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: James Thomas <jimjoe <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 29 Feb 2024 17:00:22 -0800

On 2/29/2024 3:30 PM, James Thomas via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> The current patch is much better for me personally: 'l' and 'r' now do
> what they're supposed to do. But my ideal (short of any advanced 'tree'
> mechanism), as I originally stated, would've been to _insert_ (rather
> than _replace_) the new history at the position in the current history
> where it's created (but I see that there's no SOP for that in (info
> "(elisp) Minibuffer History"), and that there could be performance
> implications).

That shouldn't be too hard to do, at the very least with the appropriate 
hooks (i.e. you might need to write some Elisp depending on how many 
built-in options we want to support, but you won't have to use 
'advice-add').

> Why not simply make 'eww-save-history' customizable?

In a general sense, that's the idea. I don't want to make 
'eww-save-history' itself customizable though, since a) I want to let 
people define a history pruning/fixup function and b) I don't want that 
customizable function to have to be responsible for saving the current 
page's history; 'eww-save-history' can do that for us. In practice 
though, I think it'll all work out about the same, albeit easier to use.

> TBH I don't think anyone would have been (ab)using it effectively
> because each 'l' or 'r' made things more complicated; but the advantage
> that *all* of history was available with 'H'.

Yeah, I think the main thing we need here is some option to prevent loss 
of existing history.

> (I'm using this patch and will let you know if I see anything amiss)

I already found one issue with reloading messing up history, but that 
was an easy fix. Once I finish up the other parts of my v3 patch, I'll 
post it here.

Message #74 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: James Thomas <jimjoe <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Thu, 29 Feb 2024 18:10:19 -0800

[Message part 1 (text/plain, inline)]

On 2/29/2024 5:00 PM, Jim Porter wrote:
> I already found one issue with reloading messing up history, but that 
> was an easy fix. Once I finish up the other parts of my v3 patch, I'll 
> post it here.

I've only lightly tested this so far, but this version adds an 
'eww-before-browse-function' option which lets you customize how EWW 
manipulates history before browsing to a new page. I've added functions 
for the default behavior ('eww-clear-future-history'), and for cloning 
all the "parent" entries ('eww-clone-previous-history')[1]. You can also 
set it to 'ignore', which will just preserve the old entries and add the 
new page to the end (which is the behavior v1 of my patch had).

I've also added more regression tests to make sure this all works as 
expected.

How does this look?

[1] See the docstring for a longer explanation of how this works.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #77 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Fri, 01 Mar 2024 09:26:41 +0200

> Date: Thu, 29 Feb 2024 18:10:19 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
> 
> On 2/29/2024 5:00 PM, Jim Porter wrote:
> > I already found one issue with reloading messing up history, but that 
> > was an easy fix. Once I finish up the other parts of my v3 patch, I'll 
> > post it here.
> 
> I've only lightly tested this so far, but this version adds an 
> 'eww-before-browse-function' option which lets you customize how EWW 
> manipulates history before browsing to a new page. I've added functions 
> for the default behavior ('eww-clear-future-history'), and for cloning 
> all the "parent" entries ('eww-clone-previous-history')[1]. You can also 
> set it to 'ignore', which will just preserve the old entries and add the 
> new page to the end (which is the behavior v1 of my patch had).
> 
> I've also added more regression tests to make sure this all works as 
> expected.
> 
> How does this look?

Thanks.  I have a usability comment below.

> --- a/etc/NEWS
> +++ b/etc/NEWS
> @@ -1004,6 +1004,18 @@ When invoked with the prefix argument ('C-u'),
>  This is useful for continuing reading the URL in the current buffer
>  when the new URL is fetched.
>  
> +---
> +*** History navigation in EWW now works like other browsers.
> +Previously, when navigating back and forward through page history, EWW
> +would add a duplicate entry to the end of the history list each time.
> +This made it impossible to navigate to the "end" of the history list.
> +Now, navigating through history in EWW simply changes your position in
> +the history list, allowing you to reach the end as expected.  In
> +addition, when navigating to a new page from a historical one, EWW

"historical" here should be in quotes (and perhaps explained in
parentheses), otherwise people might misinterpret or fail to
understand what it alludes to.

> +(defcustom eww-before-browse-function #'eww-clear-future-history
> +  "A function to call before browsing to a new page.
> +By default, this removes any entries in the history that come after the
> +current page (see `eww-clear-future-history')."

The doc string should describe the known possible values of the
option.

Now for the usability issue: It's okay to have this is a variable (to
allow future extensions, which might be unrelated to history), but
having a function for user option, and one that is more general than
being about history traversal, is not the best ides: it makes
customization harder for users who are not Lisp programmers.

Therefore, I suggest a history-specific defcustom, whose possible
values could be 'clear', 'clone', and 'add', and whose effect will be
to call the corresponding function via eww-before-browse-function.
The defcustom could also have a user-defined function value to allow
additional functions, of course.

Message #80 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Fri, 01 Mar 2024 14:20:23 +0530

Jim Porter wrote:

> On 2/29/2024 5:00 PM, Jim Porter wrote:
>> I already found one issue with reloading messing up history, but
>> that was an easy fix. Once I finish up the other parts of my v3
>> patch, I'll post it here.
>
> I've only lightly tested this so far, but this version adds an
> 'eww-before-browse-function' option which lets you customize how EWW
> manipulates history before browsing to a new page. I've added
> functions for the default behavior ('eww-clear-future-history'), and
> for cloning all the "parent" entries
> ('eww-clone-previous-history')[1]. You can also set it to 'ignore',
> which will just preserve the old entries and add the new page to the
> end (which is the behavior v1 of my patch had).
>
> I've also added more regression tests to make sure this all works as
> expected.
>
> How does this look?

I'm using it with the following:

--8<---------------cut here---------------start------------->8---

(defun eww-clone-previous-history-upto-first ()
  "Like `eww-clone-previous-history', but only clone up to the first
occurrence of the current page in the history."
  (when (> eww-history-position 1)
    (setq eww-history
	  (append
	   (cl-subseq
	    eww-history
	    (- 0 (cl-position-if
		  (lambda (elt) (equal (plist-get elt :url) (eww-current-url)))
		  eww-history :from-end)
	       1))
           eww-history))))

(setq eww-before-browse-function #'eww-clone-previous-history-upto-first)

--8<---------------cut here---------------end--------------->8---

...for getting the behaviour I'd referred to earlier:

> ... so because that might sometimes be too much, (adding to the end)
> only the entire history up to the first occurrence of the source page.

Will report back if I see any problems.

Regards,
James

Message #83 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: James Thomas <jimjoe <at> gmx.net>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 69232 <at> debbugs.gnu.org
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught
 in a loop
Date: Fri, 01 Mar 2024 17:26:54 +0530

James Thomas wrote:

> I'm using it with the following:

It had a small error; corrected version:

--8<---------------cut here---------------start------------->8---

(defun eww-clone-previous-history-upto-first ()
  "Like `eww-clone-previous-history', but only clone up to the first
occurrence of the current page in the history."
  (when (> eww-history-position 1)
    (setq eww-history
	  (append
	   (cl-subseq
	    eww-history
	    (cl-position-if
	     (lambda (elt) (equal (plist-get elt :url) (eww-current-url)))
	     eww-history :from-end))
           eww-history))))

(setq eww-before-browse-function #'eww-clone-previous-history-upto-first)

--8<---------------cut here---------------end--------------->8---

Regards,
James

Message #86 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Fri, 1 Mar 2024 12:13:08 -0800

[Message part 1 (text/plain, inline)]

On 2/29/2024 11:26 PM, Eli Zaretskii wrote:
> Thanks.  I have a usability comment below.

Thanks for taking a look.

> "historical" here should be in quotes (and perhaps explained in
> parentheses), otherwise people might misinterpret or fail to
> understand what it alludes to.

Done. I've also added a short description about this to the EWW manual 
so that people in the future know they can tweak this behavior.

>> +(defcustom eww-before-browse-function #'eww-clear-future-history
>> +  "A function to call before browsing to a new page.
>> +By default, this removes any entries in the history that come after the
>> +current page (see `eww-clear-future-history')."
> 
> The doc string should describe the known possible values of the
> option.

Done.

> Now for the usability issue: It's okay to have this is a variable (to
> allow future extensions, which might be unrelated to history), but
> having a function for user option, and one that is more general than
> being about history traversal, is not the best ides: it makes
> customization harder for users who are not Lisp programmers.

After sleeping on this, I think I agree. I had debated whether to add 
something like 'eww-before-browse-hook', but then I reasoned that I 
really want exactly *one* of these history-modification functions to run 
before browsing, so I made it '...-function'. But that's not right 
either, since it would mess things up if someone wanted to use this as a 
hook (they'd need to write their own Lisp function to do everything).

There might be some use in the future for 'eww-before-browse-hook', but 
I can't think of any off the top of my head, so I've just changed this 
to 'eww-before-browse-history-function'. If we want a more general hook 
later, we can always add it when we know more.

> Therefore, I suggest a history-specific defcustom, whose possible
> values could be 'clear', 'clone', and 'add', and whose effect will be
> to call the corresponding function via eww-before-browse-function.
> The defcustom could also have a user-defined function value to allow
> additional functions, of course.

I've done something close to this, though I retained the previous form 
where the possible values are things like 'eww-delete-future-history'. 
That keeps the code to *use* this option simpler (no special-case symbol 
names), and the only difference with your suggestion is that users who 
manually edit their init.el will have a longer symbol name to type.

For Customize users, I added 'function-item' choices so they should just 
be able to click on the option they want without having to worry about 
the exact symbol name.

If you strongly prefer to have this accept non-function symbol names 
like 'clear', let me know and I can change it. I don't care too much, 
but this way seemed simpler and easier to maintain.

[0001-When-navigating-through-history-in-EWW-don-t-keep-ad.patch (text/plain, attachment)]

Message #89 received at 69232 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Sat, 02 Mar 2024 09:38:03 +0200

> Date: Fri, 1 Mar 2024 12:13:08 -0800
> Cc: 69232 <at> debbugs.gnu.org, jimjoe <at> gmx.net
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> > Therefore, I suggest a history-specific defcustom, whose possible
> > values could be 'clear', 'clone', and 'add', and whose effect will be
> > to call the corresponding function via eww-before-browse-function.
> > The defcustom could also have a user-defined function value to allow
> > additional functions, of course.
> 
> I've done something close to this, though I retained the previous form 
> where the possible values are things like 'eww-delete-future-history'. 
> That keeps the code to *use* this option simpler (no special-case symbol 
> names), and the only difference with your suggestion is that users who 
> manually edit their init.el will have a longer symbol name to type.
> 
> For Customize users, I added 'function-item' choices so they should just 
> be able to click on the option they want without having to worry about 
> the exact symbol name.
> 
> If you strongly prefer to have this accept non-function symbol names 
> like 'clear', let me know and I can change it. I don't care too much, 
> but this way seemed simpler and easier to maintain.

I think what you did is functionally equivalent, and not harder to use
in practice.  So I'm okay with this version of the patch.  Thanks.

Message #94 received at 69232-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 69232-done <at> debbugs.gnu.org, jimjoe <at> gmx.net
Subject: Re: bug#69232: 30.0.50; [PATCH] EWW history navigation gets caught in
 a loop
Date: Wed, 6 Mar 2024 16:26:36 -0800

On 3/1/2024 11:38 PM, Eli Zaretskii wrote:
> I think what you did is functionally equivalent, and not harder to use
> in practice.  So I'm okay with this version of the patch.  Thanks.

As it's been a couple of weeks since I posted about this on emacs-devel, 
and there haven't been any further comments, I've merged this to master 
as 59e470dd5de. If there are any followup issues about this though, just 
let me know.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.