stylo: Investigate form control issues that aren't solved by fixing HasAuthorSpecifiedRules

NEW
Assigned to

Status

()

Core
CSS Parsing and Computation
P1
normal
3 months ago
3 months ago

People

(Reporter: bholley, Assigned: hiro)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Matt is working on HasAuthorSpecifiedRules in bug 1349651. We have a lot of failing form control tests though, and it's likely that some will have issues beyond HasAuthorSpecifiedRules, as evidenced by my try push at [1].

So in parallel, we should investigate what other issues there are. We can check whether a given issue is fixed by HasAuthorSpecifiedRules by just flipping the bool in [2].

Per discussion yesterday, Manish is going to look into this.


[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=34174792c241f552a07e031aef854407d0468e62
[2] http://searchfox.org/mozilla-central/rev/6e1c138a06a80f2bb3167d9dac050cc0fd4fb39e/layout/style/nsRuleNode.cpp#10449

Comment 1

3 months ago
Some relevant things from a mail I sent before I saw this bug filed:

1)  Textarea sizing is wrong.  You can see this on layout/reftests/bidi/dirAuto/dynamicDirAuto-setLTR-Auto1.html for example, but this affects a bunch of other tests.  This _may_ be due to our scrollbar issues; worth checking with an overflow:hidden textarea (which seems to be sized closer in Gecko to the size stylo sizes its textareas right now).

2)  Some tests rely on moz-appearance applying to some things but not others.  For example, layout/reftests/css-disabled/select/select-fieldset-1.html on stylo tip doesn't paint the select's dropmarker button correctly.  If we flip the boolean, that paints correctly but the <select> itself no longer does (because it _does_ have author rules applied, but we stop dropping native theming for it).  This is likely to affect a bunch of <select> tests.
(Assignee)

Comment 2

3 months ago
(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #1)

> 2)  Some tests rely on moz-appearance applying to some things but not
> others.  For example,
> layout/reftests/css-disabled/select/select-fieldset-1.html on stylo tip
> doesn't paint the select's dropmarker button correctly.  If we flip the
> boolean, that paints correctly but the <select> itself no longer does
> (because it _does_ have author rules applied, but we stop dropping native
> theming for it).  This is likely to affect a bunch of <select> tests.

This one seems to have been solved by bug 1361632.
Any idea if (1) was solved as well, or still needs to be investigated?
Flags: needinfo?(hikezoe)
Reassigning to hiro, I think he knows more about this area of the stuff. I'll continue to report tests that are still failing after fixes land.
Assignee: manishearth → hikezoe
(Assignee)

Comment 5

3 months ago
As per a try [1] based on scrollbars fixes (bug 1321754 and bug 1361632) with the tweak in comment 0,  (1) also seems to have been fixed.  On the other hand, as per another try [2] with overflow: hidden in comment 1, the textarea size still different. It looks like there is a room for scrollbar area (it might be caused by native theme style though).  I'd like to keep this bug open until bug 1349651 is fixed, and I'd rather help Matt to fix bug 1349651. Also, progress reftests still fail on the first try [1], I am going to investigate it.

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=06f7fd465e4a27b435bd1d802c653fc89e7cdab2&selectedJob=96500939
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=4356c1cb176d1ec70b57202f959dd3b851a025bb&selectedJob=96887072
Flags: needinfo?(hikezoe)
You need to log in before you can comment on or make changes to this bug.