1379566 - stylo: Stylish add-on editor doesn't show colorized text (except on first load)

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect, P1)

Description

[atlanto]

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.
...

Comment 1

[atlanto]

>Windows10, LinuxMint 18.3
s/18.3/18.2/

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Interesting regression range

Comment 3

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 5

[Bobby Holley (:bholley)]

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?

Comment 6

[Bobby Holley (:bholley)]

From talking to kmag it sounds like this is an overlay extension and not supported anymore.

Comment 7

[Caspy7]

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.

Comment 8

[Bobby Holley (:bholley)]

(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.