Can No Longer Highlight or Copy From Correct Answer In Footer (Web) After Exercise Marked Wrong

I do DuoLingo on the web and I frequently copy-and-paste material from the site's footer, after it marks me wrong in an exercise and suggests a correct answer. I find today I am no longer able to do this...there is now something in the javascript or structure of the page that prevents me from selecting and highlighting (and thus copying) the text. It is extremely aggravating and HIGHLY frustrates me that the people running this site are ACTIVELY BREAKING existing features instead of fixing the numerous bugs that I and other users have been reporting.

This is of critical importance in the newer courses, including Chinese and Japanese, where the languages use characters and I need to look them up.

I also use Google translate to read these sentences out loud, to reinforce what I'm learning. DuoLingo does not give me the option of hearing playback for the recommended correct answer (something that I'd like, and a feature I have suggested both in forums and in bug reports MONTHS ago, which frustrates me because it seems like such a feature would be trivially easy to add relative to other things the people running this site have implemented).

I find this very aggravating. Is there any workaround, perhaps a javascript hack, that anyone else has discovered?

Currently the only workaround I've figured out is going to the talk page, and copying the text from there, which really slows me down because the talk pages sometimes take five or more seconds to load.

December 13, 2017


I think I've figured out the cause of the problem. Newer versions of web browsers (Chrome at least) have changed how "auto" works for the "user-select" CSS property.

I'm still on Chrome 60, since the last few versions have problems with my computer hardware. Chrome 60 doesn't have the problem at all. But I tested Chrome Canary 64 and Firefox 57 on my computer too, and both of these do have the problem you mentioned.

Web browsers previously read the "auto" setting as meaning it should use the default setting (=user can select text). But now browsers instead interpret this "auto" differently as meaning it should inherit the property of its parent element. A few ancestors back there is an element set to "user-select: none". So this "none" gets passed down and inherited by the text you want to select.

Anyway, long story short, I made a userstyle to fix it:

To use this you need to have a userstyle extension like Stylish. Or you can instead just click the "Install style as userscript" if you already have a userscript extension (like Tampermonkey or Greasemonkey).

Should completely fix this issue. Fixes it perfectly on both Chrome 64 and Firefox 57 for me. Hope this helps some people. ^^

December 14, 2017

I think I've figured out the cause of the problem. Newer versions of web browsers (Chrome at least) have changed how "auto" works for the "user-select" CSS property.

It must have been a DL change, because I got it without in any way updating or otherwise changing my browser (Firefix 56). If your diagnosis is correct, how did it happen to me?
I assumed it was deliberate change on DL's part to discourage people from copy-pasting answers to questions they got wrong. Anyone can still hear and copy the sentence by going to the discussion page, however.

December 14, 2017

Yeah. Duo must have changed something in the CSS if this has suddenly started affecting users in only the last couple of days. However, the way it has currently been set doesn't look to me as if they were deliberately trying to prevent users from selecting the text.

The SPAN element containing the text = child of another SPAN. = child of DIV. = child of H2. = child of DIV. = child of DIV. = child of DIV. (This final DIV element is the whole "footer" bar itself, and all its descendent elements are contained within its boundaries.)

That final DIV is the only element in that list specifically set to "user-select: none". All of its descendant elements are set to "user-select: auto". The SPAN containing the text is the great-great-great-great-grandchild of that final DIV.

So "user-select: none" gets passed down by six generations before being inherited by the SPAN containing the text. But this inheriting version of "auto" by child elements only happens in the most recent versions of Chrome (62+) and Firefox (~56+). In earlier versions like mine (Chrome 60), "auto" instead meant user-select should use its default for the element type (which for SPAN elements = text is selectable).

If their primary reason was to prevent users selecting this text, they would have made sure this SPAN element was set to "user-select: none" directly (which would affect users with less recent browser versions like mine) rather than relying on inheritance to work.

In fact, the "Report", "Discuss", and "Continue" buttons are directly set to "user-select: none", even though they are all descendants of the footer bar DIV element already. So Duolingo makes doubly sure the text of these three buttons can't be selected, but just leaves the SPAN element containing the correction text sentence up to the whims of the various different browser versions. ^^

December 14, 2017

No doubt you are quite correct, then; I was merely making assumptions rather than examining the code.

The SPAN element containing the text = child of another SPAN. = child of DIV. = child of H2. = child of DIV. = child of DIV. = child of DIV.

This is really crying out for some cod-biblicallity, which I feel powerless to resist the urge to provide:

Lo, and DUO spake unto Span, father of Div, saying 'Whensoever the element that is called User thou seest, none shalt thou make selection of, even unto the last generation of thine offspring that is numberless as the sands of the Sea, for I am DUO, that hath writ thee'.
And Span was perplexed exceeding mightily, and saith: 'wherefore wouldst Thou forbid the users to copy the graven texts therefrom, O DUO, that they might better gain withal the knowledge of the Tree of Cathay and of Nippon and of the divers tongues that dwelleth upon the four corners of the Earth?'
And DUO answered him, saying: 'Did I not give unto them tiles that they should not suffer to type? But they were blind to My wisdom, and waxed haughty, and did wailing and gnashing their teeth cry unto me 'Render thou back unto us the typing boxes which thou didst take!' And I was moved, and did render back unto them the typing boxes, for I am a merciful Owl.
And verily, whereafter did they that knew not My wisdom not fall into wickedness, and typeth not, but rather copyeth and pasteth betimes the answers to the questions which I have set them? And in their copying moreover used they not Wiktionary and Cdict and divers other websites that provideth me not with advertising revenue? And so shalt thou suffer not the User to select in the sheet of style that cascadeth, for lo, I am become a wrathful Owl, and waxeth green in my jealousy.'

And Div begat Div, who begat Div, who begat H2, who begat Div, who begat Span, who begat Span that dwelt in the land of Lesson. Yea, and kept Div and his seed the selection of none which DUO had commanded him even unto a thousand generations.

December 15, 2017

Haha. Outstanding post!

I actually realised myself, towards the end of typing that paragraph, that it was beginning to sound like a geneology from the Bible. I was very tempted at the time to change it from "child of DIV" to "son of DIV". However, I thought my post was probably already complicated and confusing enough without this. Therefore, I decided I'd sadly have to let the urge to change it pass by.

So I'm very glad to see you not only added what I had wanted to write but took it much much further! I definitely enjoyed reading this.

December 16, 2017

Thanks so much, testmoogle! This is a great fix!

December 16, 2017

Still perfectly fine for me in Google Chrome on a Windows 10 PC. However, if you shrink the width of the window to less than 700 pixels wide, then the page switches from desktop site layout to mobile site layout. When it's in mobile site layout I then can't select that text either.

  • viewport width >=700px ⇒ desktop site "user-select: auto"
  • viewport width <700px ⇒ mobile site "user-select: none"

Is it instead happening for you even in desktop site layout? If so, are you using a different web browser/device to me?

December 13, 2017

[deactivated user]

    I have the same problem and frankly it has really slowed down my desire to learn.

    December 13, 2017

    I have the same problem [...]

    By "the same problem", what problem do you mean? In my post you replied to I said it's working perfectly fine for me. I don't have any problem. ^^;

    If you mean what I said about how Duo has intentionally set the mobile site to "user-select: none", and that you've made your browser window too small which has caused Duo to switch to mobile site layout (like it's meant to), then simply resize your window so that it switches back to desktop site layout to fix this.

    December 14, 2017
    • 1336

    Its "broken" on Chrome and Zilla for me. :/

    December 13, 2017

    Do you mean both for mobile site layout (what it switches to when you make the width of your browser window narrower than 700 pixels) AND for desktop site layout (wider than 700 pixels)?

    December 14, 2017

    Broken on desktop site for me.

    December 14, 2017

    Yeah, I understand what the problem is now and why my web browser (Chrome 60) is unaffected by it. Thanks for confirming the problem affects Chrome 63 though. I believe 61 and below don't have the problem. ^^

    I've now made a userstyle to fix the problem and have shared it:

    December 15, 2017
    • 1336

    I just hope all the <<<bugs>>> will be fixed, and this is their way to learn about new code, written in last couple of months, thus new bugs.

    One can only hope

    December 13, 2017

    I've noticed another issue w/the same approximate timing: sometimes the "discuss" button doesn't appear when I answer a question incorrectly.


    Has anyone seen this behavior? I'm running: - High Sierra 10.13.1 - Chrome 63.0.3239.84

    December 14, 2017

    I see that quite often now. In English to Spanish there is a new Spanish male voice that is unclear and cannot be slowed down. Also no comment area for this new voice.

    December 21, 2017

    works fine for me on Mac OSx, but not on iOS.

    December 15, 2017

    Hi Testmoogle,

    thanks for your Stylish style, I will gladly test it on Firefox ESR V52.5.2 32bit PC/Windows.

    You are right about the fact, that the "website auto-generated user script" does N O T always work.

    It is the same for "DuoLingo new lessons fix" by tiramisues:

    You need the Stylish addon; GreaseMonkey V3.18 did not work for me.

    BTW: This problem reminds of the the "locked right-side translation textarea" (white text input box), where I can NOT copy and paste anything, after I click the "Check" button.
    The text field get's locked/grey and already entered font text is also changed to grey.

    Workaround "Duolingo - Re-Enable Textareas" (Greasemonkey/Tampermonkey script) by tiramisues:

    December 15, 2017

    It's happening for me to, now that Firefox upgraded itself.

    It's quite annoying when you can't select the answer.

    December 20, 2017

    I, too, am unable to highlight as of the past few days. Frustrating! Ubuntu 16.04, Chrome 62.0.3202.94 on a desktop.

    December 21, 2017

    Thanks for confirming my speculation was correct that on Chrome this issue only occurs on version 62 and higher. :)

    No need for any frustration though. You can just install the userstyle extension "Stylish" in Chrome and then get my userstyle:

    Can just forget the problem even exists after that. ^^

    December 21, 2017

    Thank you!

    December 22, 2017
    Learn a language in just 5 minutes a day. For free.