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

[WIP] Update web/compatibility.js #4803

Merged
merged 1 commit into from
May 29, 2014
Merged

Conversation

mgol
Copy link
Contributor

@mgol mgol commented May 15, 2014

  1. Remove obsolete workarounds
  2. Add support comments

Original description:
Object.create & Object.defineProperty issues concern IE<9 and really old WebKit versions. Object.keys is universally available outside of oldIE as well, including Android 2.3. Firefox has unprefixed requestAnimationFrame long ago and the fallback to using a custom function is only slower but works.

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

It would be useful to have support comments indicating for which browsers a specific workaround is needed. In this way it'll be easier to know what workarounds can be removed in the future.

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

I suppose more things could be removed; especially related to vendor prefixes. Just waiting for feedback first.

})();

// Object.defineProperty() ?
(function checkObjectDefinePropertyCompatibility() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm, I'm against removing the checkObjectDefinePropertyCompatibility polyfill just yet. I remember fixing at least two-three bugs related to the old androids 2.3-4.1(?) and safari 5(?). Do you have stats on usage for old webkit browsers on the internet?

@yurydelendik
Copy link
Contributor

We are automatically testing PDF.js only on Firefox and Chromium browsers, and even then we are not using compatibility.js. We count on support from the community to provide feedback and fixes for "other" browsers. Do we need to wait for people to test the patch?

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux)


Received

Command cmd_preview from @yurydelendik received. Current queue size: 0

Live output at: http://107.21.233.14:8877/c83c79bbf6ba035/output.txt

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

It's possible some of these are needed for (really) old Androids; I'll try to check it and add proper comments so that the support story is clear.

@mgol mgol changed the title Remove obsolete compatibility workarounds WIP Remove obsolete compatibility workarounds May 15, 2014
@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

@yurydelendik Feedback from others would be great. :) I'm trying to make it all a little smaller since the file already has 500 lines and maybe not all of that is needed. If sth is, I'd like it to be annotated. Update to the PR coming soon.

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

(it's not urgent to merge this one fast; I'll happily wait for more feedback)

@Rob--W
Copy link
Member

Rob--W commented May 15, 2014

MDN and Can I Use provide a wealth of information about browser compatibility features, including a table with usage statistics derived from StatCounter: http://caniuse.com/usage_table.php.

@yurydelendik
Copy link
Contributor

MDN and Can I Use provide a wealth of information about browser compatibility features

Right, but there is no bug information, e.g. there are several defineProperty bugs in old browsers that are/were important for pdf.js to work properly.

@mgol mgol changed the title WIP Remove obsolete compatibility workarounds WIP Update web/compatibility.js May 15, 2014
@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

I restored a couple of workarounds with concrete support comments (I run the tests on different browsers in BrowserStack).

BTW, what was the purpose of the localStorage polyfill, where is it not available? I removed it for now in the PR but I suppose it was needed in some specific environment? Otherwise it wouldn't make much sense since the only browsers without localStorage support are extremely old.

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

I also improved the pushState check to omit buggy old Android implementations.

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

Another thing I improved were some XMLHttpRequest-related checks. Currently Chrome/Safari e.g. implement XHR#response, it's just it's populated for each request separately and not kept on the prototype. Chromium folks are working on a fix, no idea about WebKit. Anyway, the property is present on XHR objects and it's better to use them when available.

I guess pdf.js doesn't need them exactly on the prototype but on the XHR objects, right?

Changed the commit title to reflect the broader scope of this PR.\

EDIT: the relevant Chromium ticket is crbug.com/43394

// Android 2.x has so buggy pushState support that it was removed in
// Android 3.0 and restored as late as in Android 4.2.
// Support: Android 2.x
if (!history.pushState || navigator.userAgent.indexOf('android 2.') >= 0) {
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thx, fixed. I was copying from a regex with the i flag. :)

@mgol
Copy link
Contributor Author

mgol commented May 15, 2014

OK, I'm done for today with this PR. @yurydelendik, please review the changes.

EDIT: I added support comments in the form // Support: browserName<v if I know it's fixed in version v and // Support: browserName v+ if I tested the bug exists in version v and I'm not sure about the newer ones. That's the format we use in jQuery and it makes it easy to search for specific hacks. Let me know if you like it. :)

@timvandermeij timvandermeij changed the title WIP Update web/compatibility.js [WIP] Update web/compatibility.js May 15, 2014
@timvandermeij
Copy link
Contributor

How can we be sure that this does not break anything in older browsers? Can we test this somehow?

@mgol
Copy link
Contributor Author

mgol commented May 23, 2014

@timvandermeij I run the tests in compatibility.js in browsers in BrowserStack; if some of them pass the test & the polyfill is not applied, then it's not needed in this browser.

Of course, it's always possible a test was faulty, wasn't catching everything etc. but there's no way around that, people just need to test & report issues. I try to be cautious here.

1) Remove obsolete workarounds
2) Add support comments
@yurydelendik
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux)


Received

Command cmd_preview from @yurydelendik received. Current queue size: 0

Live output at: http://107.21.233.14:8877/e4b90de8aa1278d/output.txt

@yurydelendik
Copy link
Contributor

/botio-linux preview

@pdfjsbot
Copy link

From: Bot.io (Linux)


Received

Command cmd_preview from @yurydelendik received. Current queue size: 1

Live output at: http://107.21.233.14:8877/44f37e47dbc4a9a/output.txt

@yurydelendik
Copy link
Contributor

Okay, let's try this. But we probably need to run that across all devices/OSes later just to set baseline.

yurydelendik added a commit that referenced this pull request May 29, 2014
[WIP] Update web/compatibility.js
@yurydelendik yurydelendik merged commit 825762f into mozilla:master May 29, 2014
@yurydelendik
Copy link
Contributor

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants