Bug 1571756 Comment 12 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Odd... I still can't reproduce on Linux Nightly 2019-09-17. Tested on my desktop (1:1 DPI) and my laptop (HiDPI, tested with 200% and 300% scaling).

In comment 10, the threshold seems to be the point where "Bright Sparks" appears/disappears (to the right of "Worklife 101").  I was not able to reproduce any flickering when resizing my window around that threshold.

A few thoughts:
 - This might be font-dependent (which could explain why I haven't been able to repro on Linux)
 - There seems to be a bit of "fudge factor" in their decision of when to show/hide the Bright Sparks text. In Responsive Design Mode, starting with a wide viewport, the "Bright Sparks" is visible with viewport-width=896px and disappears when I drop to 895px -- but then if I go **back up** to 896px, it doesn't reappear until I get to 897px.

Anyway -- comment 11 is very helpful in explaining how Bug 1396642 may have impacted things here. Before Bug 1396642, we probably rounded the viewBox values to `0 0 108 16` under the hood. The change in behavior (supporting finer-grained values) will have made the sizing calculations more precise & slightly different here.  So whatever measurement they're doing to make the call about whether to show or hide this content, it will be getting slightly different measurements now.

The content is hiding/showing due to JS that the site is running (they add the class `nav-build-bar__links-hidden` when it becomes hidden), so the site is the one that's hiding/showing it and making decisions about when/why to do that. So I think this is just a WebCompat issue, and likely a bug in the site's JS.
Odd... I still can't reproduce on Linux Nightly 2019-09-17. Tested on my desktop (1:1 DPI) and my laptop (HiDPI, tested with 200% and 300% scaling).

In comment 10, the threshold seems to be the point where "Bright Sparks" appears/disappears (to the right of "Worklife 101").  I was not able to reproduce any flickering when resizing my window around that threshold.

A few thoughts:
 - This might be font-dependent (which could explain why I haven't been able to repro on Linux)
 - There seems to be a bit of "fudge factor" in their decision of when to show/hide the Bright Sparks text. In Responsive Design Mode, starting with a wide viewport, the "Bright Sparks" is visible with viewport-width=896px and disappears when I drop to 895px -- but then if I go **back up** to 896px, it doesn't reappear until I get to 897px.

Anyway -- comment 11 is very helpful in explaining how Bug 1396642 may have impacted things here. Before Bug 1396642, we probably rounded the given viewBox values (`0 107.9 15.8`) to `0 0 108 16` under the hood. Bug 1396642's change in behavior (supporting finer-grained values) will have made the sizing calculations more precise & slightly different here.  So whatever measurement BBC's JS is doing to make the call about whether to show or hide this content, it will be getting slightly different measurements now.

And to be clear, the content is hiding/showing due to JS that the site is running (they add the class `nav-build-bar__links-hidden` to the container for "Bright Sparks" to hide that entry), so the site is the one that's hiding/showing it and making decisions about when/why to do that. So I think this is just a WebCompat issue, and likely a bug in the site's JS.
Odd... I still can't reproduce on Linux Nightly 2019-09-17. Tested on my desktop (1:1 DPI) and my laptop (HiDPI, tested with 200% and 300% scaling).

In comment 10, the threshold seems to be the point where "Bright Sparks" appears/disappears (to the right of "Worklife 101").  I was not able to reproduce any flickering when resizing my window around that threshold.

A few thoughts:
 - This might be font-dependent (which could explain why I haven't been able to repro on Linux)
 - There seems to be a bit of "fudge factor" in their decision of when to show/hide the Bright Sparks text. In Responsive Design Mode, starting with a wide viewport, the "Bright Sparks" is visible with viewport-width=896px and disappears when I drop to 895px -- but then if I go **back up** to 896px, it doesn't reappear until I get to 897px.

Anyway -- comment 11 is very helpful in explaining how Bug 1396642 may have impacted things here. Before Bug 1396642, we probably rounded the given viewBox values (`0 107.9 15.8`) to `0 0 108 16` under the hood. Bug 1396642's change in behavior (supporting finer-grained values) will have made the sizing calculations more precise & slightly different here.  So whatever measurement BBC's JS is doing to make the call about whether to show or hide this content, it will be getting slightly different measurements now.

And to be clear, the content is hiding/showing due to JS that the site is running -- they actually move the element back and forth between different places in the DOM entirely.  They hide it by moving it to a different container with class=`nav-build-bar__links-hidden` which is `display:none` -- that's how it disappears.
Odd... I still can't reproduce on Linux Nightly 2019-09-17. Tested on my desktop (1:1 DPI) and my laptop (HiDPI, tested with 200% and 300% scaling).

In comment 10, the threshold seems to be the point where "Bright Sparks" appears/disappears (to the right of "Worklife 101").  I was not able to reproduce any flickering when resizing my window around that threshold.

A few thoughts:
 - This might be font-dependent (which could explain why I haven't been able to repro on Linux)
 - There seems to be a bit of "fudge factor" in their decision of when to show/hide the Bright Sparks text. In Responsive Design Mode, starting with a wide viewport, the "Bright Sparks" is visible with viewport-width=896px and disappears when I drop to 895px -- but then if I go **back up** to 896px, it doesn't reappear until I get to 897px.

Anyway -- comment 11 is very helpful in explaining how Bug 1396642 may have impacted things here. Before Bug 1396642, we probably rounded the given viewBox values (`0 107.9 15.8`) to `0 0 108 16` under the hood. Bug 1396642's change in behavior (supporting finer-grained values) will have made the sizing calculations more precise & slightly different here.  So whatever measurement BBC's JS is doing to make the call about whether to show or hide this content, it will be getting slightly different measurements now.

And to be clear, the content is hiding/showing due to JS that the site is running -- they actually move the element back and forth between different places in the DOM entirely.  They hide it by moving it to a different container with class=`nav-build-bar__links-hidden` which is `display:none` -- that's how it disappears. So I think this is just a WebCompat issue, and likely a bug in the site's JS.

Back to Bug 1571756 Comment 12