Bug 123293 – MediaQueryList listeners blocked by CSS media queries

• Component: JavaScriptCore
• Status: RESOLVED WORKSFORME

[Andrew Leung]

Created attachment 215111 [details]
A standalone HTML test page that illustrates the bug

# Overview

MediaQueryList listeners created using window.matchMedia and addListener() are blocked when certain CSS media queries are present.

# Steps to Reproduce

The standalone test page (attached) responds to changes to the media query "max-width: 768px", both in JS as a MediaQueryList and CSS as a media query.

1. Load the test page in a browser that is 768px wide.
2. Widen the browser by 1px, and observe the result.
3. Reload the page in place.
4. Narrow the browser by 1px, and observe the result.

# Actual Results

When the browser width goes from 768px to 769px, the answer was NO + YES. The counter incremented. When widening the browser by one extra pixel to 770px, the answer became YES + YES. The counter did not increment.

When the browser width goes from 769px to 768px, the answer was YES + NO. The counter incremented. When narrowing the browser by one extra pixel to 767px, the answer became NO + NO. The counter did not increment.

These results were obtained in these browsers:

* Safari 6.1 (8537.71) on OS X 10.8.5
* WebKit nightly build 538.4+
* MobileSafari on iPad running iOS 7.0.3

# Expected Results

When the browser width goes from 768px to 769px, the answer should be YES + YES. The counter should increment.

When the browser width goes from 769px to 768px, the answer should be NO + NO. The counter should increment.

# Additional Info

The actual results show that while the CSS media query immediately updated the page when the browser width crosses the threshold, the MediaQueryList listener did not, until the browser width changed by another pixel.

On the iPad, rotating between portrait and landscape orientations essentially changes the browser width between 768px and 1024px respectively. The same results were observed, except the browser width cannot be changed by another pixel to unblock the event/listener. In a way, this bug has a much larger impact on the iPad because of this.

[Andrew Leung]

Created attachment 215113 [details]
A standalone HTML test page that illustrates the bug

[Andrew Leung]

Just tested this on WebKit r166355, and the problem still exists.

[Andrew Leung]

Just tested this on Safari 7.1 and WebKit r173755, and the problem still exists.

The ipad is exactly where you want matchmedia to work for resoponsive design! Yes you can work around this with a resize listener, but this bug took me a while to track down. Looks like you can't vote on bugs here, but this one certainly would have mine!

[Andrew Leung]

Just tested this on Safari 8.05 and WebKit r182629, and the problem still exists.

[Andrew Leung]

Tested this again on Safari 10.0 and WebKit r206206, and the problem still exists.

To reiterate, this bug can be replicated on all Safari browsers so far, but its effect is mostly felt by iOS devices because they don't have resizable windows. On a page that uses window.matchMedia to listen to width changes, if the threshold is between the device's portrait and landscape widths, the event won't fire when orientation changes. That's the incorrect behavior.

[Ryan Fitzer]

I was *not* able to reproduce this issue on Safari 12.

OS: macOS Sierra 10.12.6
Safari: 12.0.1 (12606.2.104.1.2)

[Andrew Leung]

Same here. This is no longer reproducible in Safari running on:

* macOS 10.13.6 [Safari 12.0.1 (13606.2.104.1.2)]
* iOS 10.3.3 (iPad)
* iOS 12.0.1 (iPad)

Maybe it's fixed?