Reading a page: one posting in both JSON-LD and microdata is offered as a two-item results list #26

New issue

Closed

opened 2026-10-01 10:47:19 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:47:19 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo-chromium at 7998de372, reading readPostings in src/lib/parse.js and running it under jsdom.

readPostings promises that "the same posting written twice, in the script and in the markup, is listed once", but it keys each posting on its own address, falling back to the tab's address. When only one of the two spellings states a url, and the tab's address differs from it (a tracking query, a slug), the two keys differ. The same posting is listed twice, neither copy is here, and the popup shows the tick list for a results page instead of the correction form.

Where: src/lib/parse.js:808-809, readPostings() (const own = ownUrl(posting) || url; and the key built from sameUrl(own)); src/lib/parse.js:542-549, sameUrl(), which keeps the query; src/lib/parse.js:556-570, matchesUrl(); src/popup.js:92, which shows the pick list when more than one posting is listed and none is here.
What happens: a page whose JSON-LD states url: "https://jobs.example/j/42" and whose microdata spells the same posting without a url, read at https://jobs.example/j/42?utm_source=newsletter, gives two entries, with urls https://jobs.example/j/42 and https://jobs.example/j/42?utm_source=newsletter, both here: false (checked under jsdom against the snapshot). Read at the bare address, the same page gives one entry, here: true. The existing test (test/parse.test.mjs:32-42) covers only the case where both spellings state the same url.
Why it matters: someone who opens a posting from a job-alert link gets "this page lists 2 postings" with the same job twice and no form to review its fields; ticking both sends two captures of one posting.
Fix: before keying, give a copy without its own address the address of a copy with one when the titles (and company names, when present) agree, or key a copy without its own address on title and company alone. Separately, compare addresses without the query, or at least without utm_* and similar tracking parameters, when deciding here, so the canonical copy matches the tab it is shown in.

Related to postulo/postulo-chromium#5, which notes that sameUrl differs from the core's address key in other ways, but not this one.

Done when

test/parse.test.mjs has a case with a JSON-LD posting stating url and a microdata copy without one, read at the same address plus ?utm_source=newsletter, asserting one entry and here: true.

Found on 2026-09-29 in a read-only review of postulo-chromium at 7998de372, reading `readPostings` in `src/lib/parse.js` and running it under jsdom. `readPostings` promises that "the same posting written twice, in the script and in the markup, is listed once", but it keys each posting on its own address, falling back to the tab's address. When only one of the two spellings states a `url`, and the tab's address differs from it (a tracking query, a slug), the two keys differ. The same posting is listed twice, neither copy is `here`, and the popup shows the tick list for a results page instead of the correction form. - **Where:** `src/lib/parse.js:808-809`, `readPostings()` (`const own = ownUrl(posting) || url;` and the key built from `sameUrl(own)`); `src/lib/parse.js:542-549`, `sameUrl()`, which keeps the query; `src/lib/parse.js:556-570`, `matchesUrl()`; `src/popup.js:92`, which shows the pick list when more than one posting is listed and none is `here`. - **What happens:** a page whose JSON-LD states `url: "https://jobs.example/j/42"` and whose microdata spells the same posting without a `url`, read at `https://jobs.example/j/42?utm_source=newsletter`, gives two entries, with urls `https://jobs.example/j/42` and `https://jobs.example/j/42?utm_source=newsletter`, both `here: false` (checked under jsdom against the snapshot). Read at the bare address, the same page gives one entry, `here: true`. The existing test (`test/parse.test.mjs:32-42`) covers only the case where both spellings state the same `url`. - **Why it matters:** someone who opens a posting from a job-alert link gets "this page lists 2 postings" with the same job twice and no form to review its fields; ticking both sends two captures of one posting. - **Fix:** before keying, give a copy without its own address the address of a copy with one when the titles (and company names, when present) agree, or key a copy without its own address on title and company alone. Separately, compare addresses without the query, or at least without `utm_*` and similar tracking parameters, when deciding `here`, so the canonical copy matches the tab it is shown in. Related to postulo/postulo-chromium#5, which notes that `sameUrl` differs from the core's address key in other ways, but not this one. ## Done when - `test/parse.test.mjs` has a case with a JSON-LD posting stating `url` and a microdata copy without one, read at the same address plus `?utm_source=newsletter`, asserting one entry and `here: true`.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:47:19 +00:00

tiagoagueda added the

bug

label

2026-10-01 10:47:19 +00:00

tiagoagueda referenced this issue from a commit

2026-10-04 15:20:38 +00:00

List one posting once when only one spelling states its address

tiagoagueda closed this issue

2026-10-04 15:20:38 +00:00