|Submitter||Diff||Changes||Open Issues||Last Updated|
|Error loading review requests:|
59 bytes, text/x-review-board-request
|Details | Review|
This is in . It's somewhat annoying because it gives us a pseudo-element style... It's presumably not terrible to implement. That being said, stylo doesn't fail any text-shadow-selected-x tests right now... It's only used to set mHasSelectionShadow. But there are no text-shadow UA rules, so that will always return true iff mTextShadow is non-null, I think, except for user sheets... Anyway, need to look into it more in detail. : http://searchfox.org/mozilla-central/rev/8a61c71153a79cda2e1ae7d477564347c607cc5f/layout/generic/nsTextFrame.cpp#4111
I'm looking into whether we can actually just remove that call as well as mHasSelectionShadow.
Assignee: nobody → xidorn+moz
try looks good (as expected): https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ddde5d1b779082c7703e595ff290233ac614f3b
status-firefox55: --- → wontfix
status-firefox56: --- → wontfix
status-firefox57: --- → affected
status-firefox-esr52: --- → wontfix
This is probably OK - at least, so far I don't see why it shouldn't be, though I'd like to look at it a bit more and try to understand what the code was attempting to do. But in looking at text selection examples, I'm seeing an alarming difference between non-stylo and stylo behavior, at least on macOS. (I mention this because selection highlighting differs significantly between platforms, so it's possible this is a Mac-only regression.) Filed bug 1401317 to look into that.
Comment on attachment 8907476 [details] Bug 1384691 - Unconditionally set mHasSelectionShadow when -moz-selection pseudo element is used. https://reviewboard.mozilla.org/r/179172/#review192866 Yeah, I think it should be fine to do this. Sorry for the delay here.
Attachment #8907476 - Flags: review?(jfkthame) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/5909ec7d5d53 Unconditionally set mHasSelectionShadow when -moz-selection pseudo element is used. r=jfkthame
Status: NEW → RESOLVED
Last Resolved: 5 months ago
status-firefox58: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Does this need uplift to Beta or can it ride the 58 train?
I don't think it's important to uplift it to Beta. Let's just have it ride the 58 train.
You need to log in before you can comment on or make changes to this bug.