Closed Bug 1686613 Opened 3 years ago Closed 3 years ago

In the new non-native widget theme, if I specify padding for one side, all other sides reset to have 0 padding

Categories

(Core :: Widget, defect)

defect

Tracking

()

RESOLVED FIXED
Fission Milestone M7
Tracking Status
firefox86 --- fixed

People

(Reporter: dholbert, Assigned: emilio)

References

Details

Attachments

(5 files)

Attached file testcase 1

STR:

  1. Run Firefox with about:config pref widget.disable-native-theme-for-content set to true.
  2. Load attached testcase.

EXPECTED RESULTS:
Each pair of form controls should look the same (horizontally at least; their height / y-positioning might vary slightly)

ACTUAL RESULTS:
In the second and fourth form control, the contents are shifted to the left, and the form control is skinnier than its partner. (This is really just a symptom of its padding properties having been reset to 0 for some reason, aside from the one padding-top property that was specified explicitly on that element.)

Firefox release (without this pref set) and Chrome both give EXPECTED RESULTS here, btw.

Attached image screenshot of bug
Attachment #9196984 - Attachment description: screenshot → screenshot of bug
Fission Milestone: --- → M8

This is somewhat expected, see bug 1624696.

We should either change the UA sheet somehow when non-native theme is enabled, and remove the widget specified padding altogether, or make the AUTHOR_SPECIFIED_PADDING flags more granular, but I'd rather not do the later.

Tracking non-native theming bugs for Fission Beta milestone (M7).

Fission Milestone: M8 → M7

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

We should either change the UA sheet somehow when non-native theme is enabled, and remove the widget specified padding altogether

One slight annoyance with that is that we'd need different UA sheets for the parent and content processes (or some new MQ which checked the non-native theme pref and what type of process we're in).

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

This is somewhat expected, see bug 1624696.

We should either change the UA sheet somehow when non-native theme is enabled, and remove the widget specified padding altogether, or make the AUTHOR_SPECIFIED_PADDING flags more granular, but I'd rather not do the later.

Given comment 5, do you still prefer the first approach? What are the downsides of doing the latter? Adding granularity seems more straightforward, but I'm sure there are good reasons why this isn't the preferred approach.

Flags: needinfo?(emilio)

Adding granularity is somewhat annoying and not too expected, imo.

(In reply to Cameron McCormack (:heycam) from comment #5)

One slight annoyance with that is that we'd need different UA sheets for the parent and content processes (or some new MQ which checked the non-native theme pref and what type of process we're in).

This seems not too hard to implement, IMO. I can poke in a bit.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

The only change I've made intentionally is the change to the textarea /
input padding. Now that the focus outline doesn't cover the padding
area, this preserves the same visual effect, plus the 2px inline padding
values now match Chrome, which means that even affecting appearance:
none controls, this is probably compatible.

Depends on D102458

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/051720b8cf72
Use a consistent style for attribute selectors in forms.css. r=spohl
Keywords: leave-open
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/80240fe58a75
Add a non-native-theme media query. r=heycam
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9983175adb47
Port non-native theme paddings to forms.css. r=mstange
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Blocks: 1689044
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: