Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chrome badge doesn't track doc equivalence #2559

Closed
judell opened this issue Sep 29, 2015 · 10 comments
Closed

chrome badge doesn't track doc equivalence #2559

judell opened this issue Sep 29, 2015 · 10 comments

Comments

@judell
Copy link
Contributor

judell commented Sep 29, 2015

I'm working with a partner who will support people annotating a Drupal site. The titles (and so URLs) of the annotated articles are editable (in Drupal) by the annotators. The partner is adding a permanent URL as metadata of the form:

<link rel="canonical" href=".../drupal_node_id/...">

In this situation, annotations are immune to changes in the URL that's displayed by Drupal on the browser's URL-line. An annotation made to http://some_version_of_the_url.html will anchor to http://another_version_of_the_url.html. So far, so good!

However the Chrome badge is not immune to that change. It will show a count for http://some_version_of_the_url.html but not for http://another_version_of_the_url.html.
@lenazun
Copy link
Contributor

lenazun commented Sep 30, 2015

Can we get some actual URLs examples to test this discrepancy?

@judell
Copy link
Contributor Author

judell commented Sep 30, 2015

Yes. I can't share the partner's URLs, could fabricate equivalents, but it should be obvious if we compare the API query the app makes, which is visible in the console debugger, to the API query the badge makes, which isn't.

@nickstenning
Copy link
Contributor

Is this a report of an actual bug or a speculation of a potential one?

There's no reason at all the badge query shouldn't track document equivalence, as it uses the same search endpoint as everything else.

@judell
Copy link
Contributor Author

judell commented Sep 30, 2015

An actual bug. I'll try to recreate it based on the info and screenshots I
captured on a hangout with the partner.

On Wed, Sep 30, 2015 at 6:46 AM, Nick Stenning notifications@github.com
wrote:

Is this a report of an actual bug or a speculation of a potential one?

There's no reason at all the badge query shouldn't track document
equivalence, as it uses the same search endpoint as everything else.

—
Reply to this email directly or view it on GitHub
#2559 (comment).

@judell
Copy link
Contributor Author

judell commented Oct 1, 2015

Here is the repro:

jonudell.net/h/test1.html

<html>
<head>
<style>
body { font-family: verdana; margin: .75in }
li { margin-bottom: 10px }
</style>
</head>
<body>
This is a test.
</body>
</html>
`
image

jonudel.net/h/test2.html

<html>
<head>
<style>
body { font-family: verdana; margin: .75in }
li { margin-bottom: 10px }
</style>
<link rel="canonical" href="http://jonudell.net/h/test1.html">
</head>
<body>
This is a test.
</body>
</html>

image

@judell
Copy link
Contributor Author

judell commented Oct 6, 2015

Observation: I checked in Fiddler and the queries aren't the same on the wire. The badge does not encode the url, the sidebar does. Could it be that in the normal case that's OK but when routing through the aliasing machinery it isn't?

@nickstenning
Copy link
Contributor

URL encoding isn't part of the issue. Here's what you've done (I think).

  1. create pages A and B
  2. on page B, add a <link rel="canonical"> that points to page A (i.e. B ---> A)
  3. create an annotation on page A

Now, on creating an annotation on page B, the sidebar will detect the <link rel="canonical"> and use the URL in the link tag to describe the annotation. That is, regardless of which page you create it on, the annotation will reference page A in its target property. But it will only reference page B if you create it on page B, because on page A we have no information about page B's existence.

When you come back later with the sidebar and it executes a search query, it again detects the link tag (if present) and sends a query for the canonical URL. That is, even on page B, it will search for annotations on the URL of page A.

The badge isn't even remotely as smart as the sidebar. It just sends a query for window.location.href, assuming the server will solve all the URI normalisation and document equivalence issues for it.

This would all work fine if we actually had information on the server that page A and page B were the same. One way of creating such information would be to create an annotation on page B, which I've now done. As you can see, the badge numbers are now correct on both pages.

So the long and the short of it is this: until you create an annotation on page B, we don't have any information which tells us that page A and page B refer to the same document.

As for fixing this, there are basically two options:

  1. Make the badge smarter, and allow it to scan for page metadata.
  2. Preemptively submit page equivalence data to the server, without waiting for an annotation to be created.

My preference would be to lean towards option 2.

@judell
Copy link
Contributor Author

judell commented Oct 7, 2015

Wasn't 2) already contemplated as part of the completion of the doc
equivalence work?

On Wed, Oct 7, 2015 at 2:27 AM, Nick Stenning notifications@github.com
wrote:

URL encoding isn't part of the issue. Here's what you've done (I think).

  1. create pages A and B
  2. on page B, add a that points to page A (i.e.
    B ---> A)
  3. create an annotation on page A

Now, on creating an annotation on page B, the sidebar will detect the and use the URL in the link tag to describe the
annotation. That is, regardless of which page you create it on, the
annotation will reference page A in its target property. But it will only
reference page B if you create it on page B, because on page A we have no
information about page B's existence.

When you come back later with the sidebar and it executes a search query,
it again detects the link tag (if present) and sends a query for the
canonical URL. That is, even on page B, it will search for annotations on
the URL of page A.

The badge isn't even remotely as smart as the sidebar. It just sends a
query for window.location.href, assuming the server will solve all the
URI normalisation and document equivalence issues for it.

This would all work fine if we actually had information on the server that
page A and page B were the same. One way of creating such information would
be to create an annotation on page B, which I've now done. As you can see,
the badge numbers are now correct on both pages.

So the long and the short of it is this: until you create an annotation on
page B, we don't have any information which tells us that page A and page B
refer to the same document.

As for fixing this, there are basically two options:

  1. Make the badge smarter, and allow it to scan for page metadata.
  2. Preemptively submit page equivalence data to the server, without
    waiting for an annotation to be created.

My preference would be to lean towards option 2.

—
Reply to this email directly or view it on GitHub
#2559 (comment).

@nickstenning
Copy link
Contributor

Yep, definitely.

@nickstenning
Copy link
Contributor

I'm going to close this issue. If you want to open an issue or create a card to track the underlying issue, please do.

@nickstenning nickstenning mentioned this issue Mar 14, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nickstenning @judell @lenazun