Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IE fix: calling matchMedia with an empty string #4691

Merged
merged 3 commits into from
Jan 20, 2020

Conversation

benjaminclot
Copy link
Contributor

Type of change

  • Bugfix

Description of change

In IE, calling matchMedia with an empty string throws an error.

matchMedia throws an error if it gets an empty string as parameter on IE
@benjaminclot
Copy link
Contributor Author

As a side note, this should also be merged into the 2.44.x-legacy branch

@jsnellbaker jsnellbaker requested a review from Fawke January 6, 2020 16:24
@jsnellbaker jsnellbaker added needs review needs 2nd review Core module updates require two approvals from the core team labels Jan 6, 2020
@Fawke
Copy link
Contributor

Fawke commented Jan 7, 2020

Hi @benjaminclot,

I see your point, when we have a sizeConfig object like this:

pbjs.setConfig([{
  sizeConfig: {
    mediaQuery: '',
    sizesSupported: [
      [728, 90],
      [300, 250]
    ],
    labels: ['desktop', 'tablet']
  }
}]);

Currently, we don't have any checks in place to indicate to the user that mediaQuery string is declared an empty string.

Ideally, this shouldn't be allowed, i.e, providing an empty string for mediaQuery property. I've checked,
window.matchMedia(''), it evaluates to true in Chrome browser. In IE, as you said, it throws an error, invalid argument!

With your approach, where you are setting ruleMatch to true if mediaQuery string is empty, what would happen is all the sizes in sizesSupported will be set to true and those sizes will be available for selection when the intersection of mediaTypes.banner.sizes and sizesSupported is calculated.

For example, consider this ad unit setup.

{
    code: "ad-slot-1",
    mediaTypes: {
        banner: {
            sizes: [
                [970, 90],
                [728, 90],
                [300, 250],
                [300, 100]
            ]
        }
    },
    bids: [{
            bidder: "pulsepoint",
            labelAny: ["desktop", "tablet"],
            params: {
                "cf": "728X90",
                "cp": 123456,
                "ct": 123456
            }
        },
        {
            bidder: "pulsepoint",
            labelAny: ["desktop", "phone"],
            params: {
                "cf": "300x250",
                "cp": 123456,
                "ct": 123456
            }
        }]
}

Let's say the user is accessing the webpage from a mobile phone and viewport width is 480px. In this case, since we have configured sizeConfig[0].mediaQuery with empty string, the mediaTypes.banner.sizes will equal [[728, 90], [300, 250]] after sizeConfig filtration process is complete. [728, 90] shouldn't be included, since our viewport width is only 480px. So, the request we sent to the adapter, and SSP would be wrong.

A simple fix, that I can think of now is:

if (
      typeof config === 'object' &&
      typeof config.mediaQuery === 'string' &&
      config.mediaQuery.length > 0
    ) {
      ...
      }
    }

We can just put this extra check in place config.mediaQuery.length > 0 in the if condition. This will block out all setups where mediaQuery field is declared as empty.

Let me know what you think.

@Fawke Fawke requested a review from jsnellbaker January 7, 2020 11:00
@benjaminclot
Copy link
Contributor Author

benjaminclot commented Jan 8, 2020

Hi @Fawke,

The goal of my proposition was to have IE behave like Chrome and not introduce a potential breaking change. In your example, you deduce that [728, 90] shouldn't be included but you don't effectively know that: maybe there are edge cases where people have been using this "feature", like including a [1, 1] size, whatever the viewport is 🤷‍♂

@Fawke
Copy link
Contributor

Fawke commented Jan 9, 2020

@benjaminclot,

We'll review this internally with other prebid.js engineers and let them take a call if we should block this behaviour completely or allow it for IE (and other browsers).

@snapwich snapwich self-requested a review January 13, 2020 17:37
Copy link
Collaborator

@snapwich snapwich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this matches the behavior of chrome, then I think it's an appropriate fix for IE. LGTM

@mkendall07
Copy link
Member

In this case, since the undefined behavior is behaving differently in different browsers, we should not make the breaking change unless it's in a major release. So for now this fix is good, but @Fawke we should make the breaking change in a future 4.x release. Thanks

Copy link
Contributor

@Fawke Fawke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Merging this master. This issue will be tracked and adding mediaQuery as an empty string would be disallowed from next major version of Prebid.js

@Fawke Fawke merged commit f4475f4 into prebid:master Jan 20, 2020
@benjaminclot benjaminclot deleted the fix-ie-matchmedia-empty-string branch January 20, 2020 10:55
audiencerun pushed a commit to audiencerun/Prebid.js that referenced this pull request Jan 20, 2020
* IE fix for matchMedia

matchMedia throws an error if it gets an empty string as parameter on IE

* Removed trailing space
@Fawke Fawke removed the needs review label Feb 3, 2020
hellsingblack pushed a commit to SublimeSkinz/Prebid.js that referenced this pull request Mar 5, 2020
* IE fix for matchMedia

matchMedia throws an error if it gets an empty string as parameter on IE

* Removed trailing space
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs 2nd review Core module updates require two approvals from the core team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants