bug#17217: 24.4.50; eww/shr and relative links

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

Hi maintainers, Lars,

    emacs -Q
    M-x eww RET\
        http://franz.com/support/documentation/current/doc/classes/excl/compiler-inconsistent-name-usage-warning.htm\
        RET

Click on any link in the webpage, *eww* always reports 404, because it
couldn't follow a relative link with href="../../release-notes.htm". A
browser like chromium handles these nicely, so pressing

    C-u RETq

on a link to open it in an external browser works, would navigate to

    http://franz.com/support/documentation/current/doc/release-notes.htm

And not

    http://franz.com/support/documentation/current/doc/classes/excl/../../release-notes.htm

No idea if ../../ is standards compliant, but it would be nice to
understand it.

Thanks,
João

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-03-30 on LEG570
Repository revision: 116906 jan.h.d@swipnet.se-20140329120847-qr6hgyxpd0tk2yve
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Configured features:
XPM JPEG TIFF GIF PNG RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: C.UTF-8
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  global-edit-server-edit-mode: t
  ido-vertical-mode: t
  electric-pair-mode: t
  ido-everywhere: t
  delete-selection-mode: t
  global-auto-revert-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

joaotavora@gmail.com (João Távora) writes:

> Hi maintainers, Lars,
>
>     emacs -Q
>     M-x eww RET\
>         http://franz.com/support/documentation/current/doc/classes/excl/compiler-inconsistent-name-usage-warning.htm\
>         RET
>
> Click on any link in the webpage, *eww* always reports 404, because it
> couldn't follow a relative link with href="../../release-notes.htm". A

This patch seems to fix it,

=== modified file 'lisp/net/shr.el'
*** lisp/net/shr.el	2014-03-05 18:44:58 +0000
--- lisp/net/shr.el	2014-04-07 20:59:33 +0000
***************
*** 610,616 ****
  	 (concat (nth 3 base) url))
  	(t
  	 ;; Totally relative.
! 	 (concat (car base) (cadr base) url))))
  
  (defun shr-ensure-newline ()
    (unless (zerop (current-column))
--- 610,616 ----
  	 (concat (nth 3 base) url))
  	(t
  	 ;; Totally relative.
! 	 (concat (car base) (expand-file-name url (cadr base))))))
  
  (defun shr-ensure-newline ()
    (unless (zerop (current-column))

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

Hello Lars,

I though I had CC'ed on this bug report, but apparently I didn't. Any
change you can have a look at this before the pretest? I have commit
rights and can perform the fix, but I didn't test thoroughly.

João

>> Hi maintainers, Lars,
>>
>>     emacs -Q
>>     M-x eww RET\
>>         http://franz.com/support/documentation/current/doc/classes/excl/compiler-inconsistent-name-usage-warning.htm\
>>         RET
>>
>> Click on any link in the webpage, *eww* always reports 404, because it
>> couldn't follow a relative link with href="../../release-notes.htm". A
>
> This patch seems to fix it,
>
> === modified file 'lisp/net/shr.el'
> *** lisp/net/shr.el	2014-03-05 18:44:58 +0000
> --- lisp/net/shr.el	2014-04-07 20:59:33 +0000
> ***************
> *** 610,616 ****
>   	 (concat (nth 3 base) url))
>   	(t
>   	 ;; Totally relative.
> ! 	 (concat (car base) (cadr base) url))))
>   
>   (defun shr-ensure-newline ()
>     (unless (zerop (current-column))
> --- 610,616 ----
>   	 (concat (nth 3 base) url))
>   	(t
>   	 ;; Totally relative.
> ! 	 (concat (car base) (expand-file-name url (cadr base))))))
>   
>   (defun shr-ensure-newline ()
>     (unless (zerop (current-column))

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

Ted,

A fix has already been comitted by me, perhaps I forgot to CC
the bugtracker with a close message.

I also forgot how to do that in the meantime.

Consider also that this fix brings about a new problem on MS windows,
one that has also been
fixed for Emacs 24.4, that's bug#18310, if I'm not mistaken.

Both fixes should go into trunk when the bugfix mergeback happens
(that is If I understand
the workflow correctly).

João

On Tue, Nov 4, 2014 at 4:47 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Fri, 11 Apr 2014 16:08:52 +0100 joaotavora@gmail.com (João Távora) wrote:
>
> JT> I have commit rights and can perform the fix, but I didn't test
> JT> thoroughly.
>
> The fix works OK for me and Lars hasn't responded, so I would commit it.
>
> Ted



-- 
João Távora

bug#17217: 24.4.50; eww/shr and relative links

[Ted Zlatanov]

On Tue, 4 Nov 2014 18:42:18 +0000 João Távora <joaotavora@gmail.com> wrote: 

JT> A fix has already been comitted by me, perhaps I forgot to CC
JT> the bugtracker with a close message.

Yeah, I didn't see it.  Marking as done now, you just add "-done" to the
bug number in the reply address.

JT> Consider also that this fix brings about a new problem on MS windows,
JT> one that has also been
JT> fixed for Emacs 24.4, that's bug#18310, if I'm not mistaken.

JT> Both fixes should go into trunk when the bugfix mergeback happens
JT> (that is If I understand
JT> the workflow correctly).

I see it in the emacs-24 branch but not in trunk.  I'm not sure if it
will get ported forward by someone or you have to do it.

Author: João Távora <joaotavora@gmail.com>
Date:   Tue Aug 26 22:04:47 2014 -0700

    * net/shr.el (shr-expand-url): Plain expand-file-name is not enough;
    use url-expand-file-name.

HTH
Ted

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

OK, I can do it. At any rate I think I can do this after the git
switchover, which is
preferable to relearning bzr just for this change.

João

On Tue, Nov 4, 2014 at 6:51 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 4 Nov 2014 18:42:18 +0000 João Távora <joaotavora@gmail.com> wrote:
>
> JT> A fix has already been comitted by me, perhaps I forgot to CC
> JT> the bugtracker with a close message.
>
> Yeah, I didn't see it.  Marking as done now, you just add "-done" to the
> bug number in the reply address.
>
> JT> Consider also that this fix brings about a new problem on MS windows,
> JT> one that has also been
> JT> fixed for Emacs 24.4, that's bug#18310, if I'm not mistaken.
>
> JT> Both fixes should go into trunk when the bugfix mergeback happens
> JT> (that is If I understand
> JT> the workflow correctly).
>
> I see it in the emacs-24 branch but not in trunk.  I'm not sure if it
> will get ported forward by someone or you have to do it.
>
> Author: João Távora <joaotavora@gmail.com>
> Date:   Tue Aug 26 22:04:47 2014 -0700
>
>     * net/shr.el (shr-expand-url): Plain expand-file-name is not enough;
>     use url-expand-file-name.
>
> HTH
> Ted



-- 
João Távora

bug#17217: 24.4.50; eww/shr and relative links

[Glenn Morris]

I don't know why you guys are confused. You know the bug is closed, because

i) you (João) closed it

ii) you (Ted) had to unarchive it to have this conversation, and only
closed bugs get archived.

And the change is (of course) already in trunk thanks to the "automatic"
merging that has gone on as long as the emacs-24 branch has existed.

There's nothing to do here.

bug#17217: 24.4.50; eww/shr and relative links

[Glenn Morris]

PS Ted, whatever method you are using to find bugs, it should exclude
closed ones (certainly archived ones). Both the debbugs.gnu.org search
and (I believe) debbugs.el do so by default.

bug#17217: 24.4.50; eww/shr and relative links

[Ted Zlatanov]

On Tue, 04 Nov 2014 14:45:31 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> I don't know why you guys are confused. You know the bug is closed, because

GM> i) you (João) closed it

GM> ii) you (Ted) had to unarchive it to have this conversation, and only
GM> closed bugs get archived.

I thought archiving applied to inactive bugs, not just closed ones. So I
unarchived thinking "it's been inactive."

Thanks for explaining.

GM> And the change is (of course) already in trunk thanks to the "automatic"
GM> merging that has gone on as long as the emacs-24 branch has existed.

GM> There's nothing to do here.

That's what I thought, but I didn't see the change. It was pilot error:
I used bzr log incorrectly and missed the merge commit.

GM> PS Ted, whatever method you are using to find bugs, it should exclude
GM> closed ones (certainly archived ones). Both the debbugs.gnu.org search
GM> and (I believe) debbugs.el do so by default.

OK, thanks, will do.  Sorry for the noise.

Ted

bug#17217: 24.4.50; eww/shr and relative links

[João Távora]

Sorry Glenn for the noise indeed, so it appears I did send that
message after all.

On Tue, Nov 4, 2014 at 8:14 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 04 Nov 2014 14:45:31 -0500 Glenn Morris <rgm@gnu.org> wrote:
>
> GM> I don't know why you guys are confused. You know the bug is closed, because
>
> GM> i) you (João) closed it
>
> GM> ii) you (Ted) had to unarchive it to have this conversation, and only
> GM> closed bugs get archived.
>
> I thought archiving applied to inactive bugs, not just closed ones. So I
> unarchived thinking "it's been inactive."
>
> Thanks for explaining.
>
> GM> And the change is (of course) already in trunk thanks to the "automatic"
> GM> merging that has gone on as long as the emacs-24 branch has existed.
>
> GM> There's nothing to do here.
>
> That's what I thought, but I didn't see the change. It was pilot error:
> I used bzr log incorrectly and missed the merge commit.
>
> GM> PS Ted, whatever method you are using to find bugs, it should exclude
> GM> closed ones (certainly archived ones). Both the debbugs.gnu.org search
> GM> and (I believe) debbugs.el do so by default.
>
> OK, thanks, will do.  Sorry for the noise.
>
> Ted



-- 
João Távora

bug#17217: 24.4.50; eww/shr and relative links

[Glenn Morris]

Ted Zlatanov wrote:

> I thought archiving applied to inactive bugs, not just closed ones. So I
> unarchived thinking "it's been inactive."

No, only closed bugs ever get archived (after one month with no comments).
Open ones hang around for ever to haunt us...