Chrome (and possibly other browsers) has a feature where you can highlight a word or phrase on a website, right-click, and look it up, which gives, usually, a dictionary definition or the like (this is in addition to the feature to right-click to search for that string in Google). But it seems to not work properly in GoComics. For instance, here’s the current comic for Frazz. If I select any word in the comments, it gives me a lookup for a completely different word, often a nonsense one. For instance, the current top comment contains the word “Upstate”. If I right-click, it gives me options to ‘look up “Upstate”’, or ‘Search Google for “Upstate”’. The Google search works as expected, but when I look up “Upstate”, it tells me ‘No entries for “dvertis”, did you mean “diverts”?’, and then gives me the dictionary definition for “diverts”.
What I’ve found so far:
The actual word looked up usually seems to have the same number of letters as the word. Though it’s hard to tell sometimes what the looked-up word is.
If I select only part of a word, it usually gives me the corresponding part of the looked-up word. For instance, if I select only ‘Upstat’, it gives me ‘dverti’.
However, if the same word shows up in multiple places, it seems to get a different result each time.
It’s probably an anti web scraping mechanism that they’re using to try to fool AI crawlers and such. Probably they’re just using a font that’s substituting some characters for others? I’ll check later
Bizarre. I just tried your example, going to the comic and right-clicking and choosing “Search… for Upstate” and it worked exactly as expected. No weird words. This is in Chrome.
ETA: I was thinking “anti copy/paste” as well, but for me it does the search just fine. Must be something specific about your plugins and environment.
Yup, I’m on a Mac, and that does appear to be the same bug (at least, if the GoComics comments are done via a Shadow DOM, whatever that is).
What’s weird about it is that the word shows up correctly in the right-click menu. You’d think that, however it is that they’re fetching the word to be looked up, they’d use the same word for the right-click menu and for the lookup itself.
Yeah, I was confused at first, since Chronos described ‘right-clicking’ and didn’t mention a Mac. Chrome on my PC didn’t give an option for ‘Look up [word]’, just search with Google.
But when I tried it on my Mac (using the same ‘Upstate’ example on the Gocomics Frazz page), I see ‘Look up [word]’, and when I click it, a modal window comes up with the Wikipedia definition of the year ‘2019’. So yes, some sort of Mac/Chrome glitch, looks like.
…And now I see that the same feature appears to show up in all of my other apps, as well. I just never noticed before, because most other places a word shows up on my computer, it’s because I put it there, and so I don’t need to look it up. So this is apparently a completely OS feature, not a browser feature, so that at least explains why it sometimes has trouble retrieving the right word (and why “Search Google for…” does work, because that is a browser feature).
It’s still odd that they can retrieve the word correctly to put it on the menu option, but don’t use that same retrieval for the lookup.
I use the free version of WordWeb, and it is working fine. I’ve been using it for years, and I highly recommend it. It’s free and with no ads or strings attached.
(You might already know this) In the past, Chrome and Safari both used the same Webkit renderer, and Google and Apple worked on it together (along with the open source community). Then Google eventually decided Apple was too slow and forked Webkit into their own Blink, and ever since then, subtle bugs like this creep in once in a while.
Google controls Blink, but Blink relies on Apple APIs to do the OS “Look up” feature, and there’s a bug in what it passes from the shadow DOM to the system. The shadow DOM is a slightly obscure feature for web developers building web components… the details don’t really matter too much here.
Hi from the Chrome Mac team bug triage.
Yes, “look up” doesn’t work reliably, and expertise in Blink in the Mac team is low.
That’s from one of the Chromium maintainers, which is the open-source part of Chrome.
On a Mac, Safari generally has better performance and battery life. It also has excellent website compatibility (compared to Firefox) because all American iPhones secretly run Safari (or rather Webkit), even if the app calls itself Chrome or Firefox, so web devs regularly have to test it alongside Chrome.
But I don’t blame ya for not using it… I don’t either, lol.
My main reason to use Chrome at home is that that’s what’s on the (Windows) computers at work, and it’s easier to use the same app in both places. Well, I mean, I suppose I could use Edge at work, but…
If not, and if you cared to, reporting that as a comment on the Chromium bug report might help them track down when the bug started happening (based on macOS and Chromium versions). Up to you.
It’s probably getting part of the word ‘Advertisement’.
I commonly see that as a title on parts of a webpage that are replaced by my Adblocker.
I remember seeing similar curious things happening when working with a blind friend, who used an early screen reader on web pages. Often they read out text that was somewhere on the webpage, but not at all what you would expect to be the next word.
Yeah, I eventually figured that out by adjusting the selection. I suppose that I could, with enough patience, fully reconstruct the hidden text that it’s capturing. Or, of course, I could peek into the source code and find it there, but what fun is that?
It’s more bizarre than just targeting one specific word. It’s some sort of offset, mistakenly targeting things above and below the actual area being clicked on. It shows you one thing in the menu, looks up another thing, and highlights a third thing altogether…
This shadow DOM thing isn’t part of the web comic itself, but a SEO and commenting thing called OpenWeb (formerly Spot.IM) that they added in order to load the comments: Conversation. It injects itself into the webpage after it loads. If you add static-cdn.spot.im to your ad blocker, the injected comments won’t load and the bug won’t occur.
Just weird all around. Blink must be using some sort of coordinate based system to pass shadow DOM elements to the operating system, and maybe there’s a math error in there…
