6
\$\begingroup\$

I have a bookmarked search page which returns a set of questions within my favourite tags (e.g. and ). I have an addon that I rely on heavily, which lets me right-click on links then mark them as read from the context menu. The URLs are fine when I hover over them, but when I right click, they are changed by JS to have some extra parameters (?s=13|0.000 or the like) which breaks my ability to use this addon, because marking a different URL visited doesn't change the original.

Opening the pages works, but if I've right-clicked they'll carry that parameter, and I tend to do that first by habit. This seems to show up mainly in this search page.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ It's something related to how you are tagging for search. If I go to another SE site, I don't get that. If I take your search string and change the SE site in the URL, then I get the same append on the right click. fitness.stackexchange.com/… \$\endgroup\$
    – JohnP
    Mar 8, 2015 at 2:26
  • 1
    \$\begingroup\$ @JohnP: I see. Fun times. \$\endgroup\$
    – user17995
    Mar 8, 2015 at 2:29
  • 4
    \$\begingroup\$ I've rewritten most of your question to incorporate current knowledge (it occurs on search pages) and to make it less of an angry, verbally abusive rant. If you'd like to edit further, I invite you to do so, but I suggest you do it when you have a cooler head than when you wrote this bug report. \$\endgroup\$
    – doppelgreener
    Mar 8, 2015 at 2:37
  • \$\begingroup\$ @doppelgreener: Fair enough. Normally I'm fairly calm, but today was not a good day; I thought I'd managed to keep things OK, but I guess not so much. \$\endgroup\$
    – user17995
    Mar 8, 2015 at 2:46
  • 2
    \$\begingroup\$ I think the particulars of your search string are a red herring; I just searched “attack” and saw the same behavior. The part before the | appears to be which link you’ve right-clicked (i.e. the 1st link listed gets 1, the 2nd gets 2, and so forth). I cannot find rhyme or reason to the second part though. \$\endgroup\$
    – KRyan
    Mar 8, 2015 at 3:28
  • \$\begingroup\$ @thedarkwanderer, given that I'm specifically looking for new questions to answer, I don't see that that would be at all useful. Results would be a) somewhat stale, b) not particularly limited to questions without (suitable) answers, and c) not readily limited to those precise tags either. \$\endgroup\$
    – user17995
    Mar 11, 2015 at 2:10

1 Answer 1

Reset to default
2
\$\begingroup\$

We use the extra parameter to log the behavior of users using search and to measure if any change we make to search is effective. In particular we use that parameter to determine which were the rank and relevance of the result you clicked.

TL:DR; You need to ask the add-on author to fix the add-on, as we don't have many other feasible ways of getting this done.

I can also give you a couple of other suggestions that might bypass the problem:

  • you can use this unanswered page which is similar to your search

  • you can wait for 6-8 weeks while we revamp our question links: the current proposed solution would allow for your list to be a normal list (i.e. not a search).

\$\endgroup\$
9
  • \$\begingroup\$ Is that 6-8 weeks a real 6-8 week target for something that's planned, or as in the sense of the "sometime later" meme? I suspect the latter but many of the users here are not meta.SE savvy so some clarification would help. \$\endgroup\$
    – doppelgreener
    Mar 9, 2015 at 13:29
  • \$\begingroup\$ @doppelgreener it means that we are working on it, but we do not use estimates. It's coming later this year. Probably. ;-) \$\endgroup\$
    – Sklivvz
    Mar 9, 2015 at 13:33
  • \$\begingroup\$ Ok, thanks for clarifying. I will look forward to whatever this thingy is that is happening at some point. \$\endgroup\$
    – doppelgreener
    Mar 9, 2015 at 13:58
  • \$\begingroup\$ It's not really something the addon can reasonably fix, since it's tied to the essential nature of a URL, where protocol:string?query might be completely different from protocol:string. So doing some query string munging to consider those the same would be badly wrong in the general case. I suppose I could go ahead and adapt whatever script I come up with for this vaguely similar but less dynamic challenge, but that is of course highly SE-specific. \$\endgroup\$
    – user17995
    Mar 9, 2015 at 13:59
  • \$\begingroup\$ @doppelgreener please don't do that. We need that data to make search better. \$\endgroup\$
    – Sklivvz
    Mar 10, 2015 at 11:20
  • \$\begingroup\$ @Sklivvz My bad. I was imagining only a small number of users would use it, but then there's the odds it catches on as something a lot of people use for some reason I guess? \$\endgroup\$
    – doppelgreener
    Mar 10, 2015 at 13:24
  • \$\begingroup\$ @TuggyNE It's actually something that an addon can fix, but it introduces significant complexity and therefore might not be done. It would mean adding per-site configurability of whether to ignore the query portion of a URL for matching purposes, or even per-site regexes to find the "relevant" parts of the URL (for mixed fixed-and-variable query strings, like Google is guilty of using). But, it may be worthwhile for the author, since there are plenty of uses for the query that aren't meant to change the Unique Location meaning of a URL, such as session IDs. \$\endgroup\$
    – SevenSidedDie
    Mar 10, 2015 at 18:14
  • \$\begingroup\$ Is this the revamp you're referring to? \$\endgroup\$
    – SevenSidedDie
    Mar 12, 2015 at 17:24
  • \$\begingroup\$ Yes, how did you guess? ;-) \$\endgroup\$
    – Sklivvz
    Mar 12, 2015 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .