profile
viewpoint
Daniel Holbert dholbert Mozilla Corporation California, USA http://blog.dholbert.org

bgirard/znc-cmd-notify 24

cmd notification module for ZNC

dholbert/flexbox 2

flexbox playground, built on Knockout.js

dholbert/actix-web 0

Actix web is a small, pragmatic, extremely fast, web framework for Rust.

dholbert/arewereorganizedyet.com 0

are we reorganized yet?

dholbert/book 0

The Rust Programming Language

dholbert/browser-compat-data 0

This repository contains compatibility data for Web technologies as displayed on MDN

dholbert/cargo-update 0

A cargo subcommand for checking and applying updates to installed executables

dholbert/conduit-docs 0

Documentation for Conduit applications

dholbert/css-fixme 0

A script that adds standardised equivalents to CSS declarations that uses only prefixed code

dholbert/css-houdini-drafts 0

Mirror of https://hg.css-houdini.org/drafts

issue commentmozilla/fx-private-relay

[Button] Private relay button makes the email form look broken at joann.com

Screenshot (normal Firefox on top, vs. Firefox-with-addon on bottom): image

dholbert

comment created time in 5 days

issue openedmozilla/fx-private-relay

[Button] Private relay button makes the email form look broken at joann.com

STR:

  1. Install the private relay addon.
  2. Visit https://www.joann.com/ and scroll down to the bottom of the page, to see the "Sign up for email & save" enter-your-email box

ACTUAL RESULTS:

  • "Sign up for email & save" text is covered up
  • right border on the widget is clipped/covered

EXPECTED RESULTS:

  • Text & widget-border should still be visible.

created time in 5 days

issue commentmozilla/wg-decisions

[css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid)

clarifying the resolution (per Tab's correction in a comment on the w3c issue):

s/cause of undefined constraint/case of resolving against an indefinite constraint/

We do need a bug (and a small code change) to address this resolution.

mozilla-apprentice

comment created time in 5 days

issue commentw3c/csswg-drafts

[css-sizing] Make flex % row-gap resolve to 0 when height is indefinite (only flex, not grid)

I'm fine with the proposed flexbox change here.

(The ~sibling consistency argument feels reasonable, and it feels unlikely that someone would intentionally write content that depends on the currently specced behavior, since it causes overflow pretty reliably/trivially.)

davidsgrogan

comment created time in 6 days

issue commentwebcompat/web-bugs

www.luvaj.com - "Search" and "Cart" are not functional

If we do outreach, the simplest workaround to suggest is probably to edit the style rule at line 1040 in their style.css stylesheet:

.cd-primary-nav {
    position: static;
    padding: 50px 120px 0 190px;
    height: auto;
    width: 100%;
    float: right;
    overflow: visible;
    background: transparent;
	display:inline-block;
  }

...to add z-index: auto alongside position:static.

(Their problematic non-default z-index:1 value comes from a different style rule, which sets this element to postion:fixed. They don't intend for that z-index to have an effect when this element has position:static via the above-quoted style rule, though. Either they want it to be fixed-pos with a z-index, or they want it to be static-pos without a z-index. This is the behavior it has in WebKit/Chrome; the z-index only makes a difference for the static-pos version in Firefox due to https://bugzilla.mozilla.org/show_bug.cgi?id=1256980 .)

adamopenweb

comment created time in 6 days

issue commentwebcompat/web-bugs

www.luvaj.com - "Search" and "Cart" are not functional

@dholbert do we have known issues about pointer-events or z-index which relates to a "click through a layer"

This is just a stacking-order difference between us and Chrome.

(It's not an issue with pointer-events; that property is simply one possible hackaround, by letting clicks penetrate through elements that are in the way.)

The problem here is that <ul id="cd-primary-nav"> has z-index:1, and has the transform property set to a non-default value (which in Firefox makes it honor z-index, but in Chrome does not). So this is a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1256980

Unfortunately their transform usage seems to just be an attempt at a performance hack:

    /* Force Hardware Acceleration in WebKit */
    -webkit-transform: translateZ(0);
    -moz-transform: translateZ(0);
    -ms-transform: translateZ(0);
    -o-transform: translateZ(0);
    transform: translateZ(0);
adamopenweb

comment created time in 6 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1638937 on the SVG sizing-to-100% thing, BTW. The last piece of testcase 1 there ("Just viewBox") is the relevant bit.

cbiesinger

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

(I'm not entirely sure the 100%-svg-flex-basis thing is a Firefox bug, actually. Firefox renders these two testcases the same, which makes sense to me; whereas Chrome renders them differently [and agrees with us on the first but not the second]. The only difference between the two is flex vs. block. The interoperable behavior on the first is basically the 100% behavior that I was talking about.)

data:text/html,<!DOCTYPE html><div style="display:block;width:500px"><svg style="border:3px solid black;" viewBox="0 0 1 1">
data:text/html,<!DOCTYPE html><div style="display:flex;width:500px"><svg style="border:3px solid black;" viewBox="0 0 1 1">
cbiesinger

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

I see, that makes sense. So I think that means <svg> elements are in the special position where there's no way to give them an intrinsic BSize without also implicitly giving them a non-auto BSize and opting them out of the cross-axis stretching, perhaps.

I'm already in the process filing a gecko bug on the 100% thing here (prepping a semi-comprehensive testcase) and I'll post it here when I've filed it. Thanks!

cbiesinger

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

Thanks @dholbert ; two questions:

  • You mention an implicit width: 100%, but I didn't think SVGs did that?

I'm talking about how the lacuna value of the <svg width=...> attribute is 100%. Spec references:

If the [width/height] attribute is not specified, the effect is as if a value of '100%' were specified. https://www.w3.org/TR/SVG11/struct.html#SVGElementWidthAttribute

The value auto for width and height on the ‘svg’ element is treated as 100%. https://svgwg.org/svg2-draft/geometry.html#Sizing

(I suspect this isn't meant to actually behave as 100% in this context, though, so this may be a Firefox bug.)

  • Your last testcase is not quite right because an explicit width attribute is different from an implicit size/aspect ratio, see https://jsfiddle.net/y1z9ohpL/ and https://jsfiddle.net/y1z9ohpL/1/

Your testcase here is comparing width and height attributes against viewBox attribute.

These attributes do different things, intrinsic-sizing-wise.

The viewBox attribute only sets the intrinsic aspect ratio of a SVG element -- it does not set the intrinsic size. For an apples-to-apples comparison between <svg> and , you need to provide pixel-valued width & height attribute-values on the SVG element (even if these attributes are not present on the img element).

The width and height attributes (if given a definite value) are what provide the intrinsic size, for SVG. This is easiest to reason about in an example where we have with foo.svg containing <svg height="16" width="16" viewBox="0 0 100 100">, vs. another bar.svg which has <svg viewBox="0 0 100 100">. In both cases, the intrinsic aspect ratio is 1:1. The former case has an intrinsic size of 16x16. The latter case has no intrinsic size (but still has an intrinsic aspect ratio of 16x16).

Anyway -- the Chrome/Firefox difference on your second fiddle is merely an example of us (probably-mistakenly) using the lacuna "width=100%" value on the SVG element when establishing its flex-basis, as you can see if you add flex-shrink:0: https://jsfiddle.net/jgcnm5sL/

cbiesinger

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

Intriguingly, unlike the SVG, Firefox does not apply the right aspect ratio for <img>: https://jsfiddle.net/dgrogan/djh5wu0x/1/

@dholbert , what's up with that? :)

I'm not sure offhand why there's an img/svg difference, but Chrome & Firefox do agree on that being a difference. Here's an expanded version of your fiddle, comparing img vs. svg-with-intrinsic-size, for both stretch and flex-start -- Firefox and Chrome agree on the rendering https://jsfiddle.net/dholbert/wxr4jsg1/

cbiesinger

comment created time in 7 days

issue commentw3c/csswg-drafts

[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

In AmeliaBR's testcase with two SVG elements that she posted about above, I believe what's actually happening in Firefox is:

  • the first SVG element has a resolved flex-basis of 100px (from its specified height:100% height (cross-size) resolving against the container height, and transferring through the aspect ratio to produce a definite main-size)
  • the second SVG element has a resolved flex-basis of 220px (which I think comes from resolving its implicit width=100% attribute against the size of its container...?) It shrinks to something smaller, but if you use Firefox flex devtools or add flex-shrink:0, then you can see (in Firefox at least) that its flex-basis is 220px. (This might be a Firefox bug, not sure.) It seems like Chrome instead is treating its flex-basis as 0px here, I guess?
  • This is true for the SVG elements in the testcase-variant in biesi's response, too.

Here's a variant of Amelia's testcase with flex-shrink:0 added, to demonstrate this.

cbiesinger

comment created time in 7 days

issue commentmozilla/relman-auto-nag

Severity nag needinfos are happening for already-triaged (pre-Severity-triage switchover) tickets

(see also #964 which is similar but about emails rather than needinfo-pings)

dholbert

comment created time in 7 days

issue openedmozilla/relman-auto-nag

Severity nag needinfos are happening for already-triaged (pre-Severity-triage) tickets

On Friday of last week (May 15), when I was the layout team's weekly triage rotation, I got a series of relman-auto-nag needinfos for already-triaged bugs which had simply been filed & priority-field-triaged before the switchover to severity-based triage.

I think this was a mistake? (and I'm guessing these might continue to go out, to whoever is on the triage rotation; hence, filing this issue to see if we can avoid bothering folks with further retriage-needinfo-nags)

A few of these: https://bugzilla.mozilla.org/show_bug.cgi?id=1633410#c18 https://bugzilla.mozilla.org/show_bug.cgi?id=1633254#c14 https://bugzilla.mozilla.org/show_bug.cgi?id=1632028#c8 https://bugzilla.mozilla.org/show_bug.cgi?id=1633254#c14

created time in 7 days

issue commentwebcompat/web-bugs

www.bluedriver.com - Sub-menu options disappear when expanding the menu

(I've now added this to the "see also" list on that bug.)

eashleyfl

comment created time in 10 days

issue commentwebcompat/web-bugs

www.bluedriver.com - Sub-menu options disappear when expanding the menu

Based on your analysis, it sounds like this is https://bugzilla.mozilla.org/show_bug.cgi?id=1256980

eashleyfl

comment created time in 10 days

issue openedmozilla/fx-private-relay

relay icon is giant at https://dcwineanddine.com/

STR:

  1. Install the Private Relay extension.
  2. Visit https://dcwineanddine.com/
  3. Scroll to the bottom to the "Contact Us" section.

ACTUAL RESULTS: There is a gigantic Private Relay generate-email-address button, much larger than the email address textfield:

EXPECTED RESULTS: Reasonable-size icon, no larger than the email textfield.

My extension version is 1.3.1

Screenshot of actual results: image

created time in 18 days

pull request commentweb-platform-tests/wpt

css-flexbox: convert 7 manual-tests to ref-tests

Also, unrelated to my last comment -- for future reference, we probably shouldn't be reusing element IDs for multiple elements in the same WPT testcase. For example, in e.g. http://wpt.live/css/css-flexbox/reference/align-content_space-around-ref.html , this markup is somewhat bogus:

#spacer {
  width: 50px;
  height: 20px;
} 
...<div id=spacer></div><div id=test02>2</div><div id=spacer></div>

I guess it works, but those id=spacer divs should really be using class=spacer instead (and the CSS should have .spacer instead of #spacer), if we want to have the same CSS rule matching multiple elements.

clopez

comment created time in 23 days

pull request commentweb-platform-tests/wpt

css-flexbox: convert 7 manual-tests to ref-tests

The test align-content_stretch.html also doesn't pass with sub-pixel layout, which means it fails in Firefox on some platforms (see https://bugzilla.mozilla.org/show_bug.cgi?id=1634377 - basically we're trying to divide 50px three ways, which produces fractional pixel values)

I'll fix the test there to use 10px-taller-container (210px) as it seems we did with another test here, so that we'll end up dividing 60px three ways, which produces more predictable results. :)

clopez

comment created time in 23 days

issue openedmozilla/fx-private-relay

The "copy-to-clipboard" button should have some visual feedback when clicked

STR:

  1. Visit https://relay.firefox.com/accounts/profile/
  2. Click the "copy-to-clipboard" button to the right of a virtual email address.

ACTUAL RESULTS: Nothing visually happens, so it's not obvious that the email address was copied. (It was, but I can't tell for sure until I try pasting it somewhere. There's no easy way for me to tell whether the icon click registered or if I mis-clicked just outside of the icon, for example.)

EXPECTED RESULTS: There should be some visual feedback (the icon changing darkness, or say "Copied!", or something like that)

For comparison / prior art, github itself has a copy-to-clipboard button in its "Clone or download" section on e.g. https://github.com/mozilla/fx-private-relay/ , and that button changes darkness when it's hovered and when it's clicked, which helps me know that I targeted my click correctly and that I did indeed successfully copy the thing to the clipboard.

created time in 25 days

issue commentmozilla-mobile/fenix

Set initial page color to non-white when using dark mode

Here's a screencast of what this looks like, FWIW: https://www.dropbox.com/s/zne4d8tdfwybtnj/flash-of-white.mp4?dl=0

There's a flash of white (due to this bug) at around 0:04, while the keyboard is disappearing.

cpeterso

comment created time in 25 days

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

Indeed, looks like it. Sorry for the dupe-noise, and thanks for taking a look.

dholbert

comment created time in 25 days

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

screencast: https://www.dropbox.com/s/zne4d8tdfwybtnj/flash-of-white.mp4?dl=0 (Basically, the screen flashes white *while the keyboard-disappearing animation is happening, I think?)

dholbert

comment created time in a month

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

Screencast coming up, hosted on Dropbox. Here's a screenshot of the video player there, showing the frame of the screencast video (around 0:04) where the background is rendering as bright-white: image

dholbert

comment created time in a month

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

(Also: the color of the final page actually doesn't matter that much for this bug's reproducibility -- it just makes the flash of white easier to notice, if the pageload happens quickly.)

dholbert

comment created time in a month

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

(Also: I know sometimes this sort of flash can be caused by flash-of-unstyled-content, i.e. the webpage being partially loaded and missing some styles including its background-image or whatever. That's not what's happening here -- this bug is specifically about the coloring of the blank tab-content that's shown while the page is loading, before we've received any data for the page at all.)

dholbert

comment created time in a month

issue commentmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

As far as I can tell, what's happening here is:

  • When you hit enter to load a URL, some graphical surface gets created which is displayed during pageload.
  • If your android system theme is "dark" (regardless of your Fenix theme), then that surface will be black.
  • However, we show it as bright-white for a fraction of a second before it turns black.
  • It looks like this happens even if Fenix itself is configured for a light theme, but it's particularly noticeable/painful if Fenix has a dark theme, because it means you'll go from a dark page, to a brief instant of bright-white, back to dark.
dholbert

comment created time in a month

issue openedmozilla-mobile/fenix

[Bug] Content area briefly/blindingly flashes white before turning solid black for pageload, when Android and Fenix both configured for "dark" theme

Steps to reproduce

  1. (optional) Ideally, use a slow network connection (e.g. turn off wifi) - that makes this easier to see in isolation and reason about, since it separates the stages of pageload out over time a bit more.

  2. Set your device theme and your Fenix theme both to "dark":

  • Android settings | Display | Dark theme: "on"
  • Fenix settings | Customize | Theme: "Dark" or "Follow device Theme"
  1. In Fenix, open a new Private tab (it doesn't have to be private, but that helps -- this skips the cache, at least for the first load, which makes pageload take longer, which -- per (1) -- makes this bug easier to see in isolation, & reason about).

  2. Type in the URL for some site with a dark background, e.g.: https://spacejam.com/ https://duckduckgo.com/ (renders with a dark background if you have a dark theme) ...and hit "enter".

Expected behavior

No weird bright flashes.

Actual behavior

  • The "enter URL" pane is nice and dark, initially.
  • As I leave the "enter URL" pane, the screen flashes bright white.
  • Then the screen immediately turns black again.

This weird blinding flash is disconcerting/unsettling, and it's a rough papercut for your night vision if you're trying to browse in dark mode to rest your eyes.

Device information

  • Android device: Pixel 3
  • Fenix version: Firefox Preview Nightly, 200427 06:01 (build #21180609)

created time in a month

issue commentmozilla/fx-private-relay

[Website] "Firefox Apps" menu-icon gets into a broken state if you click it while its menu is closing

Here's a screencast of me reproducing 3x in Firefox and then once or twice in Chrome. Each time the menu closes, it's from me double-clicking the menu icon -- and then then I wait a second, and click the icon again (which you can see via the "pulse" color change on the icon), which fails to open the menu.

https://www.dropbox.com/s/g4sbni270bsblty/apps-grid-icon.webm?dl=0

dholbert

comment created time in a month

issue commentmozilla/fx-private-relay

[Website] "Firefox Apps" menu-icon gets into a broken state if you click it while its menu is closing

Odd - I can reproduce ~100% reliably, if I use a rapid double-click on the menu button (while the menu is open) to close the menu. When I do this, the next click on the menu button always gets eaten/ignored somehow.

This reliably happens for me in Firefox Nightly as well as in Chrome (on Linux, though platform probably doesn't matter much here).

dholbert

comment created time in a month

issue commentw3c/csswg-drafts

[css-align] Special case for inline-block+scroll-container elements needs to cover inline blocks that **contain** scroll containers

Thanks for that explanation! I think your bullet-points there make sense and seem to mesh with my observations from fantasai's testcase.

RE the spec edits: they make sense if I don't think about writing-modes at all. :)

But if I take writing-mode into consideration, then https://github.com/w3c/csswg-drafts/commit/7a66d53f693c973ac1f87993f6a42c88b21980dd doesn't quite make sense -- in a vertical writing-mode, I don't think it's right (or meaningful) to say that we derive the last baseline set from the margin-bottom edge... Perhaps that means to say that we derive it from the "block-end margin edge"?

That seems to be what Chrome uses for cases "B" and "I" if I load https://drafts.csswg.org/css-align-3/baseline-align-test with body { writing-mode: vertical-rl } or vertical-lr, too. But, Firefox actually seems to use the central baseline for those cases when loading the testcase in a vertical writing-mode (and we use the central baseline for most of the cases there, in fact), rather than using the perhaps-proposed block-end margin-edge. So: it seems we're not interoperable on that particular point.

(CC @jfkthame & @MatsPalmgren who may have thoughts on this, too)

dholbert

comment created time in a month

issue commentwebcompat/web-bugs

get.yourpass.eu - Slow Scrolling

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1633888

webcompat-bot

comment created time in a month

issue commentwebcompat/web-bugs

get.yourpass.eu - Slow Scrolling

I think this is an issue with scrollport targeting (i.e. Firefox deciding which scrollport to scroll, when the finger moves -- as @karlcow said, "the first touch seems to prioritize the scroll of the full page instead of just the card section"). I don't know how that code works, but I think maybe @theres-waldo might be a bit closer to that implementation & perhaps could comment.

In any case, this seems like it merits a Firefox bug report, so I'll go ahead and file one.

webcompat-bot

comment created time in a month

issue openedmozilla/fx-private-relay

[Button] The private relay button breaks the login form at https://apply.sfcu.org/ (any email that I type in is considered invalid)

STR:

  1. Visit https://apply.sfcu.org/
  2. Type in an email address, e.g. "a@example.com"
  3. Click "Submit"

EXPECTED RESULTS: The page should simply prompt you to enter a password.

ACTUAL RESULTS: The page also says "Please enter a valid email" and flags your email as invalid.

It looks like this has something to do with the Firefox Private Relay icon that's shown (or some other interaction with this addon), because if I disable the add-on, then I get EXPECTED RESULTS.

created time in a month

issue commentmozilla/fx-private-relay

[Website] the Private Relay dashboard website doesn't resize responsively when you shrink the window

screenshot (taken using Responsive Design Mode, with a 970px by 658px viewport): image

dholbert

comment created time in a month

issue openedmozilla/fx-private-relay

[Website] the Private Relay dashboard website doesn't resize responsively when you shrink the window

STR:

  1. Log in to Private Relay
  2. Visit https://relay.firefox.com/accounts/profile/ (the "dashboard")
  3. Resize your window vertically, to e.g. 1700px tall in my case.

EXPECTED RESULTS: The content should condense/recenter, or otherwise reasonably accommodate the smaller viewport height.

ACTUAL RESULTS:

  • The footer gets cut off the bottom of the window (and a scrollbar appears so I could scroll to see it).
  • The content doesn't condense or recenter, despite the fact that it's got a ton of blank space above and below the "Manage email aliases" section which is pushing stuff offscreen.

created time in a month

issue commentmozilla/fx-private-relay

Sender email address is displayed truncated in gmail

(At first I was guessing that maybe this was just broken client-side ellipsizing on Firefox's end, or something, but no -- the page's DOM literally contains the text dholbert@mozilla.co. here, and I double-checked that Chrome matches our rendering of my gmail inbox, too.)

dholbert

comment created time in a month

issue commentmozilla/fx-private-relay

Sender email address is displayed truncated in gmail

Here's what I see in my Gmail inbox: image

dholbert

comment created time in a month

issue openedmozilla/fx-private-relay

Sender email address is displayed truncated in gmail

This might be more of a Gmail bug than anything, but it's triggered by Firefox Private Relay, so I suppose it's worth reporting.

My STR: (1) I signed up for Firefox Private Relay (2) I changed my Firefox Account to use my personal email address as my primary email address. (3) I sent an email from my @mozilla.com email address to my "relay" virtual email address (4) I looked at this email in my personal Gmail inbox

ACTUAL RESULTS: In my Gmail in box view, the email is shown as being "From: dholbert@mozilla.co." If I hover that address, it shows up as a little card with that same bogus address, too.

EXPECTED RESULTS: I would expect the email address to be shown as "mozilla.com", OR I would expect the full "sender name" to be shown (ellipsized as-needed), because I think in fact what's being shown/truncated here is the sender-name which is "dholbert@mozilla.com via Firefox Private Relay" which I can see if I actually open the email.

created time in a month

issue openedmozilla/fx-private-relay

"Firefox Apps" menu-icon gets into a broken state if you click it while its menu is closing

STR:

  1. Visit https://relay.firefox.com/ (or any website that has the 3x3 grid-of-squares "firefox apps" menu at top-right. I'm not sure if this is a Relay-website-only thing or a more general Mozilla webdesign widget)

  2. Click the grid of squares near the top right, to open the Firefox Apps menu.

--> now the menu is open.

  1. Double-click the same icon, to close the menu. (Or, equivalently: click it once, and inadvertently click it again while the menu-closing-animation is playing).

--> now the menu is closed.

  1. After the menu has closed: click the icon again.

EXPECTED RESULTS: The menu should open in response to my click in step 4.

ACTUAL RESULTS: Nothing happens in response to my click in step 4.

It seems that the click-during-menu-closing gets the menu into a confused state where it doesn't know if it's open or closed. So the click in step 4 doesn't actually open it, and it looks like stuff's broken.

Note that an additional click (after step 4) does seem to successfully open the menu. So at most one click gets "eaten" & has no effect, I think. (But it still feels broken for that click to be eaten.)

created time in a month

issue openedmozilla/fx-private-relay

"Manage your firefox account" link is broken

STR:

  1. Sign in at https://relay.firefox.com/
  2. Click your profile picture at top right, to open a little menu
  3. In that menu, click "Manage your Firefox Account"

ACTUAL RESULTS: I'm taken to https://profile.accounts.firefox.com/settings, which is just some broken JSON:

{"code":404,"errno":999,"error":"Not Found","message":"Not Found"}

EXPECTED RESULTS: I should probably be taken to https://accounts.firefox.com/settings instead (which is a real page)

created time in a month

issue commentwebcompat/web-bugs

console.developers.google.com - Header tool bar is displayed truncated

Bottom line:

  • our behavior isn't entirely consistent/symmetric here, so there is room for us to improve somewhat, and it looks like that'll happen in https://bugzilla.mozilla.org/show_bug.cgi?id=1365806

  • Nonetheless, the Google folks might want to add height:0 to this element whenever they're not expecting it to take up any space (or visibility:hidden or something else similar), to more declaratively collapse or hide it.

webcompat-bot

comment created time in a month

issue commentwebcompat/web-bugs

console.developers.google.com - Header tool bar is displayed truncated

Interestingly, if I add scrollbar-color: black gray or scrollbar-width:thin to my testcase, then we do allow the scrollbar to collapse to 0.

I think this makes sense, though -- it's probably because this explicit styling causes us to draw non-native "simple" scrollbar, with a single rectangle inside of a track, which we can confidently draw at any size and hence doesn't have an intrinsic minimum size. On the other hand, when we're using the OS-native scrollbars, there are typically buttons at either end of the track & (perhaps a minimum useful size for the draggable thumb) which impose an intrinsic size on the element.

webcompat-bot

comment created time in a month

issue commentwebcompat/web-bugs

console.developers.google.com - Header tool bar is displayed truncated

(sorry, I hit "submit" by accident while typing that last comment. Continuing here:)

In Chrome, on the other hand, it seems like the vertical scrollbar only imposes a minimum intrinsic width, and it does not impose a minimum intrinsic height. (i.e. Chrome is happy for scrollbars to be indefinitely squashed so that the buttons are arbitrarily tiny). The site is depending on this behavior, even though I don't think they have a good reason to do so.

(Note that on platforms where scrollbars are "overlay-style" and don't occupy any space at all (e.g. the macOS default behavior), this is fine because the scrollbar doesn't contribute any intrinsic space to the element, because it's simply an overlay.)

webcompat-bot

comment created time in a month

issue commentwebcompat/web-bugs

console.developers.google.com - Header tool bar is displayed truncated

So -- on this element that Google is expecting to have 0 height, there is this styling (excerpted from @karlcow's broader quote above):

position:absolute;
overflow-y:scroll;

Simple testcase with a data URI to see how an element like that is sized (vertically): data:text/html,<div style="position:absolute;overflow-y:scroll;border:1px solid red"> jsfiddle: https://jsfiddle.net/dholbert/qagjer64/

In Firefox, the vertical scrollbar (which is mandatory per overflow-y:scroll) has a minimum intrinsic width and a minimum height, which means this element has that width/height as well.

webcompat-bot

comment created time in a month

issue commentmozilla/pdf.js

Fonts/text are rendered inconsistently in Santa Cruz County COVID-19 shelter-in-place PDF

Thanks! For an apples-to-apples comparison: I just checked, and I am able to reproduce this on my system, using the latest viewer at https://mozilla.github.io/pdf.js/web/viewer.html , in both Firefox 75 and Firefox Nightly. So: I suspect you're right about this being a difference in system fonts.

Having said that: do you know why things would still look better in my native PDF viewer, evince, though? (I'm assuming it has the same system fonts available as Firefox does, though maybe it has its own special store of backup/PDF-depending fonts...)

Also: as one additional bit of data, Firefox's devtools says that the rendered PDF only uses 3 fonts, for me (though I'm not sure I trust this is accurate[1]): DejaVu Sans, DejaVu Sans Mono, and Ubuntu: image

[1] (I'm not sure I trust our devtools-reported fonts here because both "AN" and "D" are reported as using DejaVu Sans, when clearly "D" is actually drawn with serifs, as shown in my initial screenshot. It looks like the reported fonts are for PDF.js's transparent "text layer" which is separate from the actual painted characters in the "canvas layer"; so I don't know if these text layer fonts are relevant here or not.

dholbert

comment created time in a month

issue openedmozilla/pdf.js

Fonts/text are rendered inconsistently in Santa Cruz County COVID-19 shelter-in-place PDF

Attach (recommended) or Link to PDF file here: https://www.santacruzhealth.org/Portals/7/Pdfs/Coronavirus/PHO%20Order%20Extending%20SIP%2020200331.pdf PHO Order Extending SIP 20200331.pdf

Configuration:

  • Web browser and its version: Firefox Nightly 77.0a1 (2020-04-21) (64-bit)
  • Operating system and its version: Ubuntu 19.10
  • PDF.js version: unsure; whatever's currently bundled with Firefox Nightly
  • Is a browser extension: I'm using the PDF.js that's built-in to Firefox Nightly (not an additional extension)

Steps to reproduce the problem:

  1. View the attached/linked PDF
  2. Look at the font & characters in the page's content (below the header) -- e.g. the section "ORDER OF THE HEALTH OFFICER OF THE COUNTY OF SANTA CRUZ DIRECTING [...]"
  3. Compare to a standalone PDF viewer.

What is the expected behavior? (add screenshot)

  • The text (starting with "ORDER OF THE HEALTH OFFICER") should mostly be displayed in a serif font. At least, that's how it's shown in my external viewer, evince. Here's a screenshot of the document up through section "1", from Evince -- note that only some small bits of the header are sans-serif: image

What went wrong? (add screenshot)

  • The text is mostly shown in a sans-serif font.
  • The font seems to change haphazardly. E.g. in the "UNDER THE AUTHORITY... AND 120175, THE HEALTH OFFICER" paragraph, just before the numbered sections start, the characters up to "AN" are sans-serif, and the letter "D" and the following leters are serif. So the font switches midway through the word "AND", which looks quite odd. Screenshot: image
  • Further down, in 1. This Order, the "T" and "O" look like they might be from a larger (or wider?) font-size than the other characters in those words. (This seems to be an issue throughout the document, with some letters being slightly wider than expected & feeling a bit unsettling.) Screenshot: image

created time in a month

issue closedmozilla/wg-decisions

[css-contain] editorial: Paint Containment description is incomprehensible

A resolution was made for csswg-drafts/#4946.

[css-contain] editorial: Paint Containment description is incomprehensible

  • RESOLVED: Accept the comment at the end of https://github.com/w3c/csswg-drafts/issues/4946#issuecomment-614501289

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue commentmozilla/wg-decisions

[css-contain] editorial: Paint Containment description is incomprehensible

In any case, I believe this resolution was effectively just a tweak to use better-defined language, and it's not calling for any behavior-change (and it matches the contain:paint behavior that we have implemented).

mozilla-apprentice

comment created time in a month

issue commentmozilla/wg-decisions

[css-contain] editorial: Paint Containment description is incomprehensible

( @heycam in case it's not a known issue, there seems to be a bug in the mozilla-apprentice bot here -- the URL seems to have been mangled in the generation of this github-issue. - and # got slash-escaped, it looks like, which broke the URL)

The correct URL (no slashes) is https://github.com/w3c/csswg-drafts/issues/4946#issuecomment-614501289

mozilla-apprentice

comment created time in a month

issue openedmozilla/secure-proxy

Secure proxy prevents Zoom Web Client from loading/working

STR:

  1. Install the FPN Secure Proxy extension
  2. Try to connect to a zoom meeting using the Zoom Web Client, by visiting https://mozilla.zoom.us/wc/join/ followed by your meeting ID

EXPECTED RESULTS: Zoom should connect to the meeting (the first sign that things are working is it'll prompt you to choose your audio input).

ACTUAL RESULTS: Zoom doesn't finish loading. The video area is black, and there's grayed-out controls at the bottom, and that's it.

I get "expected results" if I disconnect the FPN extension, vs. "actual results" if I have FPN connected.

I'm using Nightly 77.0a1 (2020-04-21) (64-bit) on Linux.

created time in a month

issue commentmozilla-mobile/fenix

[Bug] If you navigate in fullscreen mode, you get trapped in fullscreen mode forever (with browser toolbar missing from that point on)

Screencast of bug: https://www.dropbox.com/s/8xxg2h1ry5h9hek/fenix-fullscreen.mp4?dl=0

Notice that my system tray (top of screen) disappears at 0:05 when I enter fullscreen mode.

EXPECTED RESULTS are that it should reappear (and I should exit fullscreen mode) at ~0:07 after I tap the vimeo icon to navigate out of the fullscreen video to the normal vimeo.com webpage.

At 0:16, I swipe in from the edge of my screen which is the Android gesture for "give me back my 'soft' system-level back & home buttons, and also the system tray, as overlays over my current fullscreen content". But even after I reveal those buttons and tap back to return to the site I started at (after 0:17), Fenix is still stuck in fullscreen mode with no toolbar.

dholbert

comment created time in a month

issue openedmozilla-mobile/fenix

[Bug] If you navigate in fullscreen mode, you get trapped in fullscreen mode forever (with browser toolbar missing from that point on)

Steps to reproduce

  1. visit https://climaterwc.com/2020/04/16/residents-iphone-captures-compelling-footage-of-redwood-city-amid-pandemic/
  2. Scroll down to the video (at the bottom of the article text, just above the Facebook/Twitter/etc. icons)
  3. Click "play" on the video
  4. Click the fullscreen icon at the bottom-right of the video.
  5. Click the Vimeo logo at the bottom-right of fullscreened video UI. --> Note that this triggers a navigation to a normal web page (not intended to be a fullscreen experience)
  6. Try to access the browser UI (find the menu, or see if you can figure out how to switch tabs)

Expected behavior

I should leave fullscreen mode. In particular, my system tray (top of screen, with clock at the left & battery on the right) and Firefox's toolbar (bottom of screen, normally visible when I scroll appropriately) should both reappear.

Actual behavior

I remain in fullscreen mode -- the Vimeo web page occupies my entire screen. Even if I swipe in from the edge of the screen to reveal my OS "back" button, and tap that button, I'm still in fullscreen mode (Firefox's toolbar is never shown).

Device information

  • Android device: Pixel 3
  • Fenix version: Nightly 200414 12:39

created time in a month

issue commentmozilla-mobile/guardian-vpn-android

VPN icons still rendered the "connected" status even after I was disconnected

This was with version 0.9.0(900) as shown in Settings|About (and I only ever noticed this problem once).

Looks like there's a newer version available as of now; I'll post here if I hit this again with the newer version.

dholbert

comment created time in a month

issue commentmozilla/wg-decisions

[css-transforms] Zero value in perspective() function

I'm not sure if our implementation matches the requirement of "1px being the render time clamp", though. @upsuper do you happen to know?

Sorry, I initially typed this ^^ up and then meant to delete it after doing some investigation. I'm pretty sure we don't do that render-time clamp, hence the new bug. (Apologies for the spurious github-ping, @upsuper. Though: I'm happy to have you weigh in here or on the bug if you've got any additional thoughts/nuance. :) )

mozilla-apprentice

comment created time in a month

issue commentmozilla/wg-decisions

[css-transforms] Zero value in perspective() function

I think this needs a bug. Adding the bug label.

(As noted in https://github.com/w3c/csswg-drafts/issues/413 , we already had a Firefox bug filed on related stuff, https://bugzilla.mozilla.org/show_bug.cgi?id=1316236 -- but this CSSWG resolution from October 2019 requires a different behavior -- clamping small values to 1px, rather than having a discontinuity at 0 where we jump to infinity.)

I'm not sure if our implementation matches the requirement of "1px being the render time clamp", though. @upsuper do you happen to know?

mozilla-apprentice

comment created time in a month

issue closedmozilla/wg-decisions

[css-grid-2][css-grid] `grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values

A resolution was made for csswg-drafts/#4362.

[css-grid-2][css-grid] `grid-template-rows/columns` Computed / Resolved Values for 'subgrid' values

  • RESOLVED: Accept Mat's proposal which is that resolved value unwraps repeat notations and does not insert track sizes for subgrid

Discussion.


To file a bug automatically for these resolutions, add the bug label to the issue.

If no bug is needed, the issue can be closed.

closed time in a month

mozilla-apprentice

issue openedmozilla-mobile/guardian-vpn-android

VPN icons still rendered the "connected" status even after I was disconnected

No idea how this happened, but my Firefox VPN on Android got into a broken/misleading state today.

Details:

  • Initially, I was connected to the VPN.
  • After some time, I was disconnected (this happens to me periodically, not sure why; see #187 where I discuss this as well).
  • After some more time, I opened my Firefox VPN app, and it showed a broken/inconsistent state: ** The slider & globe icon rendered as if I were still connected... ** ...but the text said that I was not connected -- it said "VPN is off. Turn it on to protect your entire device"

Screenshot: Screenshot_20200415-133209

created time in a month

issue openedmozilla-mobile/fenix

[Bug] Private tab homescreen-text isn't quite accurate (or at least easy to misread)

Steps to reproduce

  1. Tap the mask at top right of Firefox Preview to switch to private-tabs mode. (I'm assuming you don't have any private tabs open.)
  2. Look at the explanatory text.

Actual behavior

The explanatory text begins: Firefox Nightly clears your search and browsing history when you quit the app [...]

Taken literally, this phrase is not true. Firefox Nightly does not clear my search/browsing history, (generally) when I quit the app. It only clears search/browsing history from private tabs.

Expected behavior

A qualifier of some sort to make this statement more precise. Maybe: "Firefox Nightly clears your private tabs' search and browsing history when you quit the app

created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

Bottom line, anyway: for the purposes of this pull request, I suspect we can agree that this particular test should not be migrated to WPT at this point, since its core expectation turns out to be something that is Blink-specific and not well-defined in the relevant specs.

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[Gecko Bug 1626146] Adjust expected height in WPT test flexitem-stretch-image.html to account for image hypothetical height being influenced by its used main size.

(I guess the "Community-TC" task is the one that matters since it's tagged as Required. I tried to see if I could retrigger the failing task there, but it looks like I lack sufficient permissions [which is probably appropriate since I'm not super familiar with the WPT continuous integration stuff and don't fully trust myself to know what to do].)

moz-wptsync-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[Gecko Bug 1626146] Adjust expected height in WPT test flexitem-stretch-image.html to account for image hypothetical height being influenced by its used main size.

RE the two task-failures here:

(1) The Community-TC failure seems to be from a network disconnect/timeout during the Chrome testrun there. The log from that task ends with socket.error: [Errno 104] Connection reset by peer

(2) For the "upstream/gecko" task: that's flagged as "failing" with "Landed on mozilla-central" (and indeed, this has landed on mozilla-central; this is a change that happened in mozilla-central which is being upstreamed). @jgraham, do you know if that's normal? Is there a reason that's flagged as "failing"?

moz-wptsync-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

I claim that clip-path:url(#c) and clip-path:inherit-which-resolves-to-url(#c) should behave the same, but they don't behave the same in Chrome.

[...] So it seems your claim is really that they are not the same (don't reference the same thing).

I'm claiming (or at least, expecting) the following: a computed style of url(#c) for some <url>-valued property on a given element should produce a consistent rendered output. The rendering shouldn't depend on where this computed value ultimately comes from (i.e. whether it's inherited from ancestor A vs. inherited from ancestor B vs. being explicitly specified). If it did make a difference, then that difference would need to be reflected in the computed value somehow, I would expect.

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

Thanks for chiming in, @fsoder!

Right, "incorrect assertion" is what I meant (at least for a WPT), rather than "test bug" - sorry for imprecise language.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1069931 on the Chrome behavior here.

I'd be happy to be shown a definite reference that the element resolution should happen at used value time

Well, the burden of proof is kind of on the folks adding a web platform test to show that the WPT's expectations are correct & grounded in well-defined/specced behavior, I think. :)

If url(#c) were to be the resolved element #c than having that with inherit seems pretty consistent too, no?

That suggests that a single computed value url(#c) would have different semantics depending on where it inherits from, which feels wrong & counter to the way that CSS works.

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

Here's a testcase, prodding this behavior a bit more, using fill: url(#whatever) instead of clip-path: url(#whatever), to be a bit easier to visualize & reason about: https://jsfiddle.net/dholbert/gf4juhq6/

  • Firefox renders rects 1,2,3 purple and 4,5 as green.
  • Safari renders 1,2 purple, 3 orange, and 4,5 green.
  • Chrome renders 1,2,3,4 purple and 5 as green.

This test here is focusing on the behavior of rect number 4, basically (where a url(...) expression is inheriting across a shadow DOM boundary), and Chrome seems to be on its own with its behavior, and seems inconsistent (it seems clear to me that rects 4 and 5 should have the same behavior, and indeed Firefox & Safari agree on this).

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

You can see what I mean about Chrome's inconsistency if you edit the test to change inherit to url(#c) in this JS:

div.shadowRoot.innerHTML =
'<div style="width: 100px; height: 100px; background-color: green; clip-path: inherit; border-right: 100px solid red"></div>';

This change doesn't affect Firefox's rendering (which make sense to me), but it does affect Chrome's rendering (in a way that makes it agree with Firefox -- the change makes Chrome start showing the red block). Chrome's inconsistency on this seems like it's indicative of a Chrome bug, not a Firefox bug.

chromium-wpt-export-bot

comment created time in a month

pull request commentweb-platform-tests/wpt

[css-masking] Migrate clip-path-inherit-across-scope-boundary.html to WPT

I think this may be a test bug.

The clip-path is, in fact, inheriting just fine (i.e. the div inside of the shadow-DOM does end up with computed clip-path: url(#c). However, that clip-path has no effect. And Chrome agrees with us that it should have no effect, if I explicitly specify the value clip-path: url(#c); on the element inside the shadow root (rather than using clip-path:inherit on that element).

I claim that clip-path:url(#c) and clip-path:inherit-which-resolves-to-url(#c) should behave the same, but they don't behave the same in Chrome. So this seems like a case where Chrome is being inconsistent, and Firefox is being consistent. (And the test happens to exercise the side of Chrome's inconsistency that Firefox does not agree with.)

Is there spec text saying that inherit is supposed to magically transfer the node (in a way that the the literal value url(#c) would not be able to access)?

CC @fsoder who I think is the test author in case he has any insight here (if I'm not picking the wrong github user; apologies if I am)

BTW it looks like this test dates back to https://bugs.chromium.org/p/chromium/issues/detail?id=769774 -- and from a quick skim, it sounds like that bug was about architectural / structural work and I don't see any discussion/mention of intended changes or special behavior about scope boundaries or shadow-DOM there. So I'm not immediately seeing a justification for this behavior.

chromium-wpt-export-bot

comment created time in a month

issue commentwebcompat/web-bugs

app.slack.com - design is broken

@miketaylr do you know if we have any contacts we could reach out to?

(BTW, I sent a note via the slack "Give Feedback" link in their help menu, with a link to this issue-page. I'm hoping that might reach the right person, but just in case it doesn't, it'd still be good to exercise other channels that we might have to get this addressed, since it's a pretty easy workaround with clear user benefit.)

dholbert

comment created time in 2 months

issue commentwebcompat/web-bugs

app.slack.com - design is broken

The issue here is with this ancestor of the image:

<div class="c-message_attachment">
  [...]
  <div class="c-message_attachment__body">

Here, <div class="c-message_attachment"> is a flex container, and its flex item <div class="c-message_attachment__body"> has this styling:

.c-message_attachment__body {
    flex: 1;
    [... snip ...]
    width: 100%;

https://a.slack-edge.com/bv1-8-8cacda2/client-boot-styles.40d02ab.css

They're relying on width:100% to implicitly clamp the resolved min-width:auto value here, but it doesn't in Firefox right now, because of https://bugzilla.mozilla.org/show_bug.cgi?id=1316534 (we currently match an older version of the spec that says to only do that clamping if flex-basis is auto).

We should really fix bug 1316534 and update to match the current spec on this, but in the meantime, we should ask Slack if they can work around this by adding min-width:0 to the above-quoted CSS rule for .c-message_attachment__body { ... }. I don't think that should have any side effects in this case, and it'll fix this brokenness in Firefox. @miketaylr do you know if we have any contacts we could reach out to?

dholbert

comment created time in 2 months

issue openedwebcompat/web-bugs

app.slack.com - design is broken

<!-- @browser: Firefox 77.0 --> <!-- @ua_header: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0 --> <!-- @reported_with: -->

URL: https://app.slack.com/

Browser / Version: Firefox 77.0 Operating System: Linux Tested Another Browser: Yes Chrome

Problem type: Design is broken Description: Items not fully visible Steps to Reproduce: wide images are clipped in slack threads (with redesigned slack UI)

STR:

  1. Create a "thread" in some slack room.
  2. Paste this URL (or the URL of some wide image) into that thread: https://pocket-syndicated-images.s3.amazonaws.com/5df8fc2de1fd4.jpg
  3. Make your browser window kinda skinny (say, ~1000px wide)

ACTUAL RESULTS: The image runs off the right side of the thread pane. EXPECTED RESULTS: The image should shrink to fit.

Firefox gives "actual results". Chrome gives "expected results".

This is a version of https://bugzilla.mozilla.org/show_bug.cgi?id=1331692 . I'll post more details below. <details><summary>View the screenshot</summary><img alt='Screenshot' src='https://webcompat.com/uploads/2020/4/3a868d4b-4f03-4524-ba2f-db18ae68d9b2.jpg'></details>

<details> <summary>Browser Configuration</summary> <ul> <li>None</li> </ul> </details>

From webcompat.com with ❤️

created time in 2 months

issue commentw3c/csswg-drafts

subtree-visibility CSS property

Another bit of feedback on a sentence in the green note below the property-definition:

The fact that off-screen elements with subtree-visibility: auto are skipped is a rendering performance optimization.

This wants s/that/that some/

(Otherwise, it can be misread as implying that all off-screen elements with subtree-visibility: auto will be "skipped". And that's not true, per the definition of "auto" - there are more requirements besides simply being offscreen.)

chrishtr

comment created time in 2 months

issue commentw3c/csswg-drafts

subtree-visibility CSS property

One bit of feedback from reading the spec:

The concept of "skipped" is a bit fuzzy right now. The spec defines it in a descriptive way right now, as if it's a classification that some elements naturally fall into:

skipped: an element is considered skipped if its subtree is not painted or hit-tested.

... but then later it uses the term as if it's an classification that can be applied by the UA, which has prescriptive requirements (e.g. subtree-visibility:hidden is defined saying "The element is skipped.").

These usages need to be harmonized, probably by rewriting the definition of "skipped" such that it's prescriptive rather than descriptive. e.g. perhaps rephrasing as "if an element is skipped, it must not be painted or hit-tested [...]" or similar.

chrishtr

comment created time in 2 months

issue commentwebcompat/web-bugs

everyman.co - Image preview is not displayed

@dholbert do we have a known core bug to dupe this against?

It's essentially a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1316534 .

It has to do with one element:

<div class="product-gallery relative flex-item-5 width-10" ...>

(which is an ancestor of the stuff that ends up really wide, when the bug happens). It's a flex item, which is why its default min-width has some magic to it.

There are two targeted possible workarounds that we could suggest for the site to apply, in the meantime, by tweaking the style of that specific element (no need for *-selector rules - that's overkill here).

They could: (1) add min-width:0 to that element ...or: (2) give that element flex: 5 auto instead of flex: 5

(The former is probably the cleanest.)

The exponential blowup (the fact that the width gets progressively more giant as you resize the window / trigger relayout) is not entirely our fault -- the site is watching for resizes & measuring the content and then setting the CSS width of some element to be the result of performing some arithmetic on that measurement. And we're yielding a measured size that is dependent on the size of the content, which the site is not expecting. So there ends up being a feedback loop where the site's requested width increases the measurement that we return, which increases the next width that the site sets, which makes us yield a still-bigger measurement, etc.

webcompat-bot

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Move flex-one-sets-flex-basis-to-zero.html test to WPT

Note https://web-platform-tests.org/writing-tests/ahem.html has this recommendation on using the Ahem font in tests:

An explicit (i.e., not normal) line-height should also always be used

Hence my recommendation to use line-height:1 here. (To simplify the CSS a bit, you could say font: 14px/1 Ahem; instead of the 3-line font-size/family/line-height specification.)

(side note: that page also says "make sure its computed font-size is a multiple of 5px" but that's primarily for the purpose of baseline alignment, so it's not necessarily worth reworking the test to follow that convention. But if you wanted to change all the 14px font-sizes and expected heights/widths to 15px or 20px, it would be incrementally better from that guideline's perspective as well. But anyway, I believe line-height:1 is all that's needed in order for the test to pass in Firefox.)

chromium-wpt-export-bot

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Move flex-one-sets-flex-basis-to-zero.html test to WPT

Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=1627602 was filed today to sync the changes, but it hasn't gotten far enough to spawn a bug for the test failures.

Anyway -- the problem here is that these checks are all essentially measuring the height of a single line of Ahem text, but they're never setting the line-height css property, so they get the default value which gives a browser-defined behavior.

The test needs to add line-height:1 to the .flexbox > div { ... } rule. With that, I believe the test passes in Firefox, based on my observations of element sizes in devtools after I've made that change.

@Gyuyoung would you mind making that change?

chromium-wpt-export-bot

comment created time in 2 months

issue commentweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

Understood. I'm glad there's an improved process to catch these sorts of issues up-front going forward. Thanks to you folks for you responsiveness over the past week!

dholbert

comment created time in 2 months

pull request commentweb-platform-tests/wpt

Add test for ResizeObserver with zoom

The test calls window.internals.setPageZoomFactor(2); -- is that an actual web API defined anywhere?

(or is it a Blink and/or WebKit-specific internal API?)

cathiechen

comment created time in 2 months

issue commentweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

Thanks for the update! I've added a reminder to be sure we've got it marked as passing in our tree, once we've sync'ed it down.

dholbert

comment created time in 2 months

issue commentweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

Thanks everyone - looking at the "After fix" wpt.fyi link, it does indeed look like the only remaining failures here are the "category (3)" failures (3/4/9/10/13/14), and per https://github.com/web-platform-tests/wpt/issues/22580#issuecomment-607381316 those tests should probably be removed or relaxed.

dholbert

comment created time in 2 months

issue commentmozilla-mobile/fenix

[Bug] Fenix opens the verge articles 2x as slow as Bromite

I duped that bug to https://bugzilla.mozilla.org/show_bug.cgi?id=1516552 (looks like this is just a version of that).

yoasif

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Move flex-flow-auto-margins-no-available-space-assert.html test to WPT

To be clear, the presence/absence of overlay scrollbars wasn't really the problem in this particular case.

My gripe here is the unexplained & almost-certainly-bogus data-expected-height=30210272 (which presumably is the humongous height that Chrome computes under some configurations, but likely isn't based on much besides that).

But in any case, I appreciate the sentiment & appreciate you all taking a look. :)

chromium-wpt-export-bot

comment created time in 2 months

issue commentweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

(2) Pieces of the test are too small for scrollbars to show up in, on some platforms

(On my machine at least, category (2) is responsible for subtests 1, 2, 5, 6, 11, and 12 failing in Firefox, I'm pretty sure. I noticed that all of these subtests fail in Firefox 76 as well as [chromium-based] Edge 83, according to WPT.fyi, so this isn't just a Firefox-specific problem, too.)

dholbert

comment created time in 2 months

issue commentweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

CC @cbiesinger @davidsgrogan @tonikitoo

dholbert

comment created time in 2 months

issue openedweb-platform-tests/wpt

WPT test css/css-flexbox/overflow-auto-006.html has a number of problems

This recently-added WPT test has a number of problems.

WPT.fyi link to view results: https://wpt.fyi/results/css/css-flexbox/overflow-auto-006.html?label=experimental&label=master&aligned

WPT.live link to run the test directly: https://wpt.live/css/css-flexbox/overflow-auto-006.html

(1) While it passes in Chrome, it fails if you view it with 200% zoom level, which is a sign that it might have some rounding issues.

(2) Pieces of the test are too small for scrollbars to show up in, on some platforms (at least, that seems to be the case when I run the test under Firefox's test-runner on my HiDPI machine -- this uses tiny 100%-pixel-scaling content but large-and-usable scrollbars, which should be fine, but seems to make this test fail.)

(3) Subtests 3,4, 9,10,13,14 fail in every browser besides Chrome, due to an assumption that overflow:auto elements should contribute their scrollbars to their intrinsic size. See https://bugzilla.mozilla.org/show_bug.cgi?id=764076#c7 for why this is problematic.

created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Migrate content-height-with-scrollbars.html to WPT

( CC @cbiesinger @davidsgrogan )

chromium-wpt-export-bot

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Migrate content-height-with-scrollbars.html to WPT

This WPT test mistakenly assumes/expects that scrollbars occupy space -- but they don't, if they're overlay-style. So the test fails in both Firefox and Chrome on Android (at least). Here are links that you can use to see this yourself: http://wpt.live/css/css-flexbox/content-height-with-scrollbars.html http://wpt.live/css/css-flexbox/reference/content-height-with-scrollbars-ref.html

See https://bugzilla.mozilla.org/show_bug.cgi?id=1626212#c2 for more details/analysis.

Not sure what the best course of action is here (backing out vs. leaving it in and annotating it as failing on platforms with overlay scrollbars)... Just posting here as an FYI for now.

chromium-wpt-export-bot

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Move flex-flow-auto-margins-no-available-space-assert.html test to WPT

(CC @cbiesinger as well since it looks like he was involved with the gerrit code review)

I 'm a bit surprised this testcase made the jump into WPT in its current state, honestly, given: a) the weird/cursed magic-number in the expected value b) the lack of any comments explaining (or self-evident reason for) where that magic number comes from c) the fact that not even Chromium passes the test right now

In the future it would be great if reviewers & patch-authors could keep these sorts of things in mind, as part of the checklist of things to look at & check for when auditing tests that are going to be added to WPT.

(Right now I'm digging out from a pile of new WPT tests that were recently added to WPT & which fail in Firefox, and cases like this one are kinda frustrating.)

chromium-wpt-export-bot

comment created time in 2 months

pull request commentweb-platform-tests/wpt

[css-flexbox] Move flex-flow-auto-margins-no-available-space-assert.html test to WPT

Hi folks... This test fails in all browsers, as shown here: https://wpt.fyi/results/css/css-flexbox/flex-flow-auto-margins-no-available-space-assert.html

It has extremely-cursed-looking styling & expectations:

* {
    display: flex;
    padding-bottom: 20pt;
    min-height: 0.7%;
    margin-top: 6000%;
    flex-shrink: 0;
    flex-basis: 7000%;
}

<abbr data-expected-height=30210272>
    <input></input>
</abbr>

This element is expected to be exactly thirty million, two hundred and ten thousand, two hundred and seventy two pixels tall. (no obvious reason why the test would be expecting precisely that height)

And it's not actually that height, even in Chrome.

Can we back this test out, and/or fix it to have valid expectations? @Gyuyoung @davidsgrogan

chromium-wpt-export-bot

comment created time in 2 months

issue commentmozilla-mobile/guardian-vpn-android

"Debug" button spawns an email to "some@email.com" (in Settings|Get Help)

Here's a screenshot -- this is what I see after I perform the STR.

Screenshot_20200327-130326

dholbert

comment created time in 2 months

issue openedmozilla-mobile/guardian-vpn-android

"Debug" button spawns an email to "some@email.com" (in Settings|Get Help)

STR:

  1. In Settings | Get Help, tap "Debug" --> Android will prompt you which app to share the log with
  2. Choose Gmail (or an email app)

ACTUAL RESULTS: A ready-to-send email is populated for me, addressed to the literal email address "some@email.com".

EXPECTED RESULTS: The email should be populated either with an empty email address, or with a legitimate Mozilla email address.

created time in 2 months

issue openedmozilla-mobile/guardian-vpn-android

App updates cause the VPN to silently disconnect

STR: (1) Wait until the Play Store shows that you've got an update available for Firefox VPN. (Don't update yet, though)

(2) Open the Firefox VPN app and connect.

(3) Switch to Google Play Store, and accept the Firefox VPN app update.

ACTUAL RESULTS: Firefox VPN silently disconnects (and its icon in your Android tray disappears). It don't get any notification or warning that I'm unprotected.

EXPECTED RESULTS: Not sure what's feasible, but we should avoid silently disconnecting, if at all possible. e.g. perhaps (if doable):

  • reestablish the VPN connection automatically so the user is only in a not-protected state briefly
  • or show some messaging to let the user know that an update was just installed & they might need to reconnect
  • or maybe we should just prevent automatic updates (of our own app) while the VPN is connected
  • or maybe something else (again, no idea what's possible)

created time in 2 months

issue openedmozilla-mobile/guardian-vpn-android

FPN android-notification says "You disconnected", even though I might not have done anything to cause the disconnection

This is just a wording concern.

I've noticed two things when using FPN:

(1) After I've had FPN connected for a while (many hours, I think?), it tends to automatically disconnect for some reason). (I'm not sure if this is common or it's just me -- it's possible it's due to my "Google Fi" VPN automatically co-opting my phone's VPN configuration after some period of time, and forcing FPN off?)

(2) Whenever I become disconnected, I get an Android notification saying:

VPN is off
You disconnected

I'm specifically filing this bug about that wording.

MY CONCERN: The phrase "You disconnected" sounds like it's saying that I took some action that resulted in the VPN disconnecting. This is often incorrect, & it can cause confusion. ("Wait, it says You disconnected, but I don't remember disconnecting... Did I accidentally mash the button? [no, I did not]")

SUGGESTION: Reword this language to something clearer, that doesn't imply that I personally/intentionally took any action. For example, maybe it should say:

  • "You are disconnected"
  • "You were disconnected"
  • ...or maybe we don't need to bother with the second line of text at all? (It already says "VPN is off" which is maybe enough information?)

created time in 2 months

issue commentmozilla-mobile/fenix

[Bug] on some URLs, tapping the URL to enter search screen does not highlight whole URL

However the actual results you specified are expected behaviour AFAIK

No, they aren't the expected behavior.

I do understand that comments/ is added as an autocomplete, but the point of this bug (I think) is that we should not directly autocomplete-extend the contents of the URLbar until the user types something. If the user simply taps the URLbar, they rightly expect us to show them an editable field which contains the current URL. (On the other hand, if they type "goo" or whatever, then sure, autocompleting makes sense.)

Cheap-Skate

comment created time in 2 months

issue commentmozilla-mobile/fenix

[Bug] on some URLs, tapping the URL to enter search screen does not highlight whole URL

I hit this today as well, FWIW, and I'm using the pixel's built-in GBoard as my keyboard (not switfkey or any other custom keyboard).

My STR: (1) Have both https://www.reddit.com/r/firefox/ and https://www.reddit.com/r/firefox/comments/ in your autocomplete history (i.e. have visited both of those URLs before) (2) Visit the first (shorter) URL. (3) Tap the URL bar.

EXPECTED RESULTS: The (now-editable) URL/search textfield should initially show me the URL that I currently have open. ACTUAL RESULTS: The URL/search texfield is immediately autocompleted beyond the URL that I'm currently on, and it shows up as https://www.reddit.com/r/firefox/comments/ even though that's not the page that I'm viewing.

Another way of saying this: if I'm viewing some page, and I tap the URL bar and then hit "enter" on the keyboard, it should effectively be equivalent to a reload operation (I shouldn't end up at a new/different URL). Right now, if I do this while viewing https://www.reddit.com/r/firefox/ , I instead end up at https://www.reddit.com/r/firefox/comments/

Cheap-Skate

comment created time in 2 months

more