Closed Bug 1379566 Opened 3 years ago Closed 3 years ago
stylo: Stylish add-on editor doesn't show colorized text (except on first load)
When layout.css.servo.enabled=true, the editor of Stylish add-on is broken. Text color becomes all black(syntax coloring is lost), so they are unreadable with dark theme(Compact Dark). STR: 0. Setup latest nightly and new profile, set layout.css.servo.enabled=true, install Stylish add-on(2.0.7), add a style for test, ... 1. Start nightly and open any web page 2. Open Add-ons Manager -> User Styles 3. Click 'Edit' to open the editor, and close the editor 4. Click 'Edit' again AR: Text color becomes all black. ER: Colored with syntax coloring. mozregression: 5:56.31 INFO: Last good revision: 06ec956f753346236bf89f2bead2066d22778fc2 5:56.31 INFO: First bad revision: 5115e2dea29a22fbaac7ad9db8723de762ec4ddd 5:56.31 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=06ec956f753346236bf89f2bead2066d22778fc2&tochange=5115e2dea29a22fbaac7ad9db8723de762ec4ddd OS: Windows10, LinuxMint 18.3 Also, the editor flashes at first time opening(on step.3 above). 'Save'(edit and save) recovers coloring temporariry. ...
>Windows10, LinuxMint 18.3 s/18.3/18.2/
Interesting regression range
I can reproduce the problem on a local stylo-enabled Linux build from m-c tip. With stylo off the user style editor shows colorized text every time you hit 'Edit'. With stylo on it colorizes only the first time, after that it shows up as black text. I haven't yet verified the regression range, will do that next with a local backout of the relevant patches.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Stylish add-on editor is broken when servo enabled → Stylish add-on editor is broken when stylo enabled
Component: Graphics → CSS Parsing and Computation
Summary: Stylish add-on editor is broken when stylo enabled → stylo: Stylish add-on editor doesn't show colorized text (except on first load)
Shoot, I lost my comment with mid-air collision. Here it is: I was still able to reproduce the problem with the backout. So I ran mozregression on the profile: ./mach mozregression -g 2017-06-23 -p obj-host-opt/tmp/scratch_user/ and was able to reproduce it on the 2017-06-23 build as well. Since that's the first build that has stylo available, I'm pretty sure this is just a stylo bug.
3 years ago
Priority: -- → P3
AFAICT Stylish isn't a WebExtension (yet?). I do know that it's popular though. Kev, do you know what the story is on Stylish? What, if anything, should the stylo team have on its radar in terms of Stylish compat for 57?
From talking to kmag it sounds like this is an overlay extension and not supported anymore.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
I understand that Stylish isn't supported anymore, but it would be interesting to know what was happening here. Notably, if it's something that still can be triggered by some other valid action. Perhaps no use following down the rabbit hole, but presumably Stylish wasn't doing anything "wrong" to trigger this.
(In reply to Caspy7 from comment #7) > I understand that Stylish isn't supported anymore, but it would be > interesting to know what was happening here. Notably, if it's something that > still can be triggered by some other valid action. > Perhaps no use following down the rabbit hole, but presumably Stylish wasn't > doing anything "wrong" to trigger this. Yeah - I'm not sure how the editor panel was set up though. If it was using XUL stuff, it might be hitting weird interactions given that we don't support stylo for XUL documents yet. Anyway, would love it if anyone could reduce an HTML page out of this with a styling bug, would get that prioritized immediately. We just don't have cycles to chase this right now given how uncertain it is to affect the web.
You need to log in before you can comment on or make changes to this bug.