Some textarea elements not recognised as such in Vivaldi
-
Including the text input on this forum!
As you can see, the text input box is bright white against a sepia backdrop. That shouldn't be the case, as Dark Reader styles <textarea> elements, but it's as if Dark Reader, and other extensions such as wasavi (which doesn't work at all when this happens), don't know what to make of these elements. Note that this doesn't happen in any other browsers I've tested, and in my testing it only happens on the Vivaldi forums and on Coreplus (which is a website that nobody here uses, in all likelihood). I've also tested with all extensions turned off on a clean profile and the same error persists. It's been like this for several versions now and I wonder if anyone could enlighten me as to what might be going on, and how I can fix it?
-
Nobody has any ideas? I kinda need Wasavi to work on Coreplus, otherwise I can't paste formatted clinical notes. A bit of a show-stopper for me in terms of using V as my daily driver.
-
@purgat0ri Hi, no idea. I logged in on Vivaldi Forum on a clean profile of 6.1.3035.300 (Stable channel) (64-bit), installed Dark Reader and set it to "Sepia" max. Input Textarea field was styled dark as expected.
This is on Win10 though. Possibly this is a MacOS specific issue - so maybe someone with Macks can test.
What you could do is use Devtools to inspect the textarea element. You should see something like this:
As you can see, the textarea has a
<style>
- this is explicitly set by the DR extension, not from the page or the browser defaults. You can also see the.skin-dark
class has its colours overridden by the explicit style.If you do this yourself you might be able to figure out where this white background is coming from.
I suspect some interference from DarkReader and this "Wasavi" extensions causing this.
-
Thank you, @Pathduck.
I disabled dark reader and ran the inspector to investigate the text area in both Vivaldi and Edge. I couldn't see any difference between the two, except that, as you can see from the screenshots, Wasavi was successfully invoked in Edge, but not in Vivaldi.
Edge running wasavi to edit the textarea in Coreplus:
Wasavi not running in Vivaldi:
-
@purgat0ri I don' think any Wasabi stuff would show up in the element inspector - it would be more interesting when testing only with Dark Reader.
Does the same happen on all textarea elements when using Dark Reader?
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea
https://interactive-examples.mdn.mozilla.net/pages/tabbed/textarea.htmlI really have no idea what's going on with your system, would be good to have someone with MacOS to test this. Might be a bug specific to MacOS, and would be good to have it reported once it's been confirmed by someone on the same OS.
-
@Pathduck said:
Does the same happen on all textarea elements when using Dark Reader?
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea
https://interactive-examples.mdn.mozilla.net/pages/tabbed/textarea.htmlI really have no idea what's going on with your system, would be good to have someone with MacOS to test this. Might be a bug specific to MacOS, and would be good to have it reported once it's been confirmed by someone on the same OS.
I tested on mac with dark reader only. Textarea on first link indeed shows up as white. Rest of right panel has dark background but still black text. Screenshots below. Second link appears normal.
I also tested on latest chrome with dark reader on mac. Everything works normally there, dark background with light text including textarea.
You may also notice in the screenshot that the dark reader extension icon has filled up the entire top bar in my browser. Just noticed that today, haven't loooked into it yet. Very strange behavior.
-
@easyme OK, maybe not good test cases, as the W3Schools is inside an iframe and the MDN one is already dark...
Some simpler and maybe better test cases:
https://pathduck.github.io/test/spatial-navigation/
https://placenamehere.com/photographica/js_textareas.html
https://a11ysupport.io/tests/html/html/textarea.html
https://www.nvaccess.org/files/nvdaTracAttachments/388/textarea.htmlThese all show up as dark with light text here on Windows.
I guess someone'll just have to report it for MacOS.
-
@Pathduck said in Some textarea elements not recognised as such in Vivaldi:
Some simpler and maybe better test cases:
https://pathduck.github.io/test/spatial-navigation/
https://placenamehere.com/photographica/js_textareas.html
https://a11ysupport.io/tests/html/html/textarea.html
https://www.nvaccess.org/files/nvdaTracAttachments/388/textarea.htmlThose links all work for me. Dark bg light text with dark reader on mac.
The w3c page is an iframe, but that shouldn't mean dark reader doesn't work. Dark reader handles the iframe correctly on chrome, so something is different in vivaldi.
Just now for the first time, I see the preview pane as I type this message is not handled by dark reader. Typing pane has dark bg, preview pane has light bg (but quoted text has dark bg). Screenshot below.
It wasn't like this before. Every other post I made, preview pane was also dark. It seems dark reader is misbehaving lately. Or could be related to forum upgrade today?
I checked the dark reader background console, only one error reported. Doesn't seem relevant but
Fetch API cannot load rms://rms:answers:SharedStaticAssets:navchevrons_top Refresh. URL scheme "rms" is not supported.
-
@easyme I don't know - I'm not an expert on these things. All I know it seems to work fine on Windows when I test in a clean profile of Vivaldi 6.1 Stable + Dark Reader.
I guess you'll need to investigate to get as much info as possible, testing in a clean profile etc and then report a bug.
And use the devtools to figure out where that white background is coming from.
The preview-container isn't even a
textarea
so there's that theory out the window... but you can see it gets itsbackground-color
from Dark Reader with the explicit<style>
element.The forum was updated just now so might be some caching stuff going on your side too. Use the Ctrl+F5 or clear cache first.
Since I don't see the problem and not on MacOS there's nothing I can do except try to give you pointers how to check on your system.
-
@Pathduck said:
Since I don't see the problem and not on MacOS there's nothing I can do except try to give you pointers how to check on your system.
Sure no worries. It's not my issue. I'm willing to help some but hopefully the OP takes charge of reporting.
And use the devtools to figure out where that white background is coming from.
On w3c page, the only stylesheet applied is the default one. Dev tools Styles panel only shows one rule:
textarea { user agent stylesheet ... background-color: field; }
Chrome shows 3 rules applied to same textarea, two from dark reader and one from default stylesheet. Not sure why dark reader isn't picking up the textarea in vivaldi.
The preview-container isn't even a
textarea
so there's that theory out the window... but you can see it gets itsbackground-color
from Dark Reader with the explicit<style>
element.That theory isn't dead yet. Textarea may be one trigger, while preview pane triggers a different issue. Indeed the behavior is different. w3c textarea has dark text on light bg, while preview pane shows light text on light bg. And rest of w3c iframe has dark text on dark bg.
It appears that some style rules are applied by dark reader, while others are missing. The cause is still anyone's guess.
HTH,
-
@easyme Yes, but where does the white background in preview pane come from on your side?
If it falls back to user agent stylesheet it means it's using the default style which is white.
-
@Pathduck said in Some textarea elements not recognised as such in Vivaldi:
@easyme Yes, but where does the white background in preview pane come from on your side?
If it falls back to user agent stylesheet it means it's using the default style which is white.
Yes that's exactly what's happening. Perhaps this screenshot will make it more clear:
I believe the italics text and "user agent stylesheet" indicates these are builtin styles from default browser stylesheet.
The relevant style is background-color: field as in my previous post. Style list is too long to capture that line in my screenshot. You'll see I put "background" in the style filter field but it still shows all the other styles under the textarea rule, because filtering is broken (it's a chromium issue not a vivaldi issue).
-
I'm not a web developer, so I'm a bit lost at the moment
The only reason I brought Dark Reader up was because I had a theory that perhaps Vivaldi was not recognising some <textareas> for certain pages as textareas and that is, perhaps, why neither extension (Wasavi or Dark Reader) seemed to be picking them up. I don't really care whether Dark Reader picks them up: it's Wasavi that is essential to my work. But after looking at the web inspector, it seems that Vivaldi is picking up the <textarea> on Coreplus as such, but Wasavi still cannot be invoked to edit it. Wasavi works on all the other websites @Pathduck has shared, and it works on Coreplus in Brave, Edge, and Firefox. I'm at a loss as to why it doesn't work with Vivaldi.
-
@purgat0ri I really don't know. From the testing done by @easyme it does seem to be limited to MacOS. Would be nice to have some more confirmation before I can say "go ahead and report it" though.
Maybe the problem is input/textareas inside iframes. The other examples do not use iframes.
Here's one more test:
https://www.tutorialrepublic.com/codelab.php?topic=faq&file=jquery-inject-html-into-an-iframe-from-the-textareaAnd here's the W3Schools one from earlier:
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textareaThese are both nested inside iframes.
You'll need to figure out if it happens with only Wasabi, only DarkReader or both. Make sure to disable all other extensions when testing. Use Ctrl+F5 to reload the page as well to bypass any caching issues. -
@Pathduck Aha! I think you might be on to something here. In both those examples, I cannot invoke wasavi for the textareas on the right hand side (I assume they are the ones nested in iframes?) in Vivaldi, but I can in Firefox and Edge.
-
@purgat0ri OK - strange that it should only affect MacOS though. I can't test in Windows right now but will do later.
What about Dark Reader - does it style those textareas inside frames?
And you even had problems with the Forum posting input - but that's not inside an iframe.
Please just go ahead and report a bug, and I will try to get confirmation on the internal Sopranos chat.
https://vivaldi.com/no/bugreport/
Post the VB# you get after reporting.Make sure to include as much detail as possible, links to test cases and info on your system and how to reproduce in a clean profile.
-
@Pathduck No, Dark Reader is not styling the textareas inside those iframes:
Interestingly, the issue is no longer occurring on the Vivaldi forum. The textarea is working with both Dark Reader and wasavi now:
Thanks for your help. I'll get on with posting that bug report
-
I did some testing here with Chrome 116:
Vivaldi 6.2 Snapshot (Chromium 116):
So looks like Dark Reader on Vivaldi is unable to trigger on iframes at all?
Also, does not look like Wasavi is able to trigger on textareas inside iframes at all, on any browser? On both sites, it's able to trigger on the left side, not inside the textareas on the right, which are nested inside another iframe.
BUT - on this test case with plain old HTML elements:
https://pathduck.github.io/test/spatial-navigation/
BOTH DR and Wasavi seems to work fine. Maybe there's some nesting limit?So this needs further investigation I think - conclusion is "it's complicated"
-
Did a test:
https://pathduck.github.io/test/nested-iframes/Welp, there's that theory out the window!
-
@Pathduck said in Some textarea elements not recognised as such in Vivaldi:
Did a test:
https://pathduck.github.io/test/nested-iframes/Welp, there's that theory out the window!
Yep. In my testing, I am able to invoke wasavi in iframes in both Edge and Firefox. Curiously, though, I cannot invoke it with a keyboard shortcut, but only by virtue of the right-click menu. That workaround used to work for Vivaldi as well, but after some or other update (it was quite some time ago, so I'm not sure which) this workaround stopped working.