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

Add support for HTML5-History-API (IE9) and support older browsers. #111

Closed
smeijer opened this issue May 13, 2015 · 21 comments
Closed

Add support for HTML5-History-API (IE9) and support older browsers. #111

smeijer opened this issue May 13, 2015 · 21 comments
Assignees
Labels

Comments

@smeijer
Copy link

smeijer commented May 13, 2015

flow-router currently does not support IE9. Adding HTML5-History-API (html5 history polyfill) will fix this. page.js mentioned supporting it, should be great if flow-router does likewise.

@smeijer smeijer changed the title Add support for HTML5-History-API Add support for HTML5-History-API (IE9) May 13, 2015
@arunoda
Copy link
Contributor

arunoda commented May 18, 2015

Okay sure. I'll have a take on this.

@arunoda arunoda changed the title Add support for HTML5-History-API (IE9) Add support for HTML5-History-API (IE9) and support older browsers. Jun 8, 2015
@arunoda arunoda added doing and removed feature labels Jun 21, 2015
@arunoda arunoda self-assigned this Jun 21, 2015
@krstffr
Copy link

krstffr commented Jun 26, 2015

Any estimate on when this will be implemented? Cheers!

@niallobrien
Copy link

Modern JS frameworks have ditched support for non-evergreen browsers, so I don't see it being a problem here. Perhaps add it as a config option for those of us who don't want it and prefer clean, hash-free urls?. :)

@arunoda
Copy link
Contributor

arunoda commented Jun 29, 2015

Yes. It's not we are going to cut down features. But to see how it works
with some polyfills :)
On 2015 ජූනි 30, අඟහ at පෙ.ව. 4.52 niallobrien notifications@github.com
wrote:

Modern JS frameworks have ditched support for non-evergreen browsers, so I
don't see it being a problem here. Perhaps add it as a config option for
those of us who don't want it and prefer clean, hash-free urls?. :)


Reply to this email directly or view it on GitHub
#111 (comment)
.

@arunoda arunoda assigned pahans and unassigned arunoda Jun 30, 2015
@pahans
Copy link
Contributor

pahans commented Jun 30, 2015

hi, I have tried adding html5-history-api polyfill. But it seems page.js does not support ie9 properly. Ran in to this issue visionmedia/page.js#259 . working on a fix at the moment

@pahans
Copy link
Contributor

pahans commented Jul 2, 2015

sent a PR to page.js. visionmedia/page.js#288

@alanning
Copy link
Contributor

page.js already added support for the History polyfill: visionmedia/page.js#109 but as you discovered the slash issue still messes up ie9.

A lot of people have tried to get this fixed in page.js:

For a bit of history, every single previous Meteor router has faced trouble with IE support, going all the way back to the venerable Router:

Tom played a big part in getting page.js updated by working with Devote to get PR109 in there.

What we did in Router and mini-pages was use a patched version of page.js and automatically include the html5-history-api polyfill. Not actually sure how iron-router does it.

Older meteorite packages exist for history and patched page.js:

Those would probably need to be updated to work with the new package system.

We talked with MDG a long time ago about adding some kind of support for conditional loading of packages based on browser capabilities or version but nothing ever came of it. Would be really nice to not have to deliver HTML5-History-API to everyone but putting it in public causes timing issues. Basically the router starts doing something before the lib is downloaded. May not be an issue with FlowRouter though since there is the wait and initialize functionality.

@alanning
Copy link
Contributor

So I think to get IE9 support working you can create a new package with the patched page.js and then rely on that instead of the upstream version. At least until upstream gets patched. Then users who are interested in supporting IE9 can install the History polyfill.

First step, anyways. Not sure what compatibility issues will come up. The polyfill will use hashes "#" to emulate push state so it limits apps in that way (can't use it for other things like tabs or anchor links). But that would only affect apps that care about IE9 support so should be OK.

@arunoda
Copy link
Contributor

arunoda commented Jul 29, 2015

I think, I agree with you. We can use a different package to get patched page.js and rely on that. I think that's gonna work.

@alanning
Copy link
Contributor

alanning commented Aug 5, 2015

Good news, using patched page.js and the history polyfill gets us a lot closer to full IE9 support.

Test Results

* Current                                = 52 failures out of 117 tests
* With patched page.js and html5-history =  2 failures

The Client - import page.js test fails consistently.

There are two other tests that sometimes fail:

  • Client - Router - subsReady - with no args - all subscriptions ready
  • Client - Route - Reactivity - watchPathChange when routeChange

I've never seen them fail together at the same time though.

Testing setup

To easily test in IE9, you can use the virtual machine images that Microsoft provides for free here: http://dev.modern.ie/tools/vms/

Tom already has new versions of his two packages on Atmosphere so I used those to test with:

  • tmeasday:html5-history-api
  • tmeasday:page-js-ie-support

@arunoda
Copy link
Contributor

arunoda commented Aug 5, 2015

Great. @pahans also working on using the patched version directly.
Let's see.

@alanning
Copy link
Contributor

alanning commented Aug 5, 2015

The Client - import page.js test is failing because the old version of page.js that tmeasday's package uses attaches itself to the window object which the test detects and fails.

Using @pahans's patched version should fix that test.

@pahans, the best way to handle this is probably to do just what Tom did and publish a "wrapper" package to atmosphere with your patched version. Would you like me to do it?

@pahans
Copy link
Contributor

pahans commented Aug 5, 2015

@alanning I think we have a even better way of doing this. let me try that and i will update you soon.

@alanning
Copy link
Contributor

alanning commented Aug 5, 2015

Ok, thanks

@alanning
Copy link
Contributor

alanning commented Aug 5, 2015

Nice! All tests passing on IE9, Chrome latest, and Firefox latest.

Cool that you can reference a tar.gz straight from Npm.depends.

@pahans pahans closed this as completed in c3366b0 Aug 6, 2015
arunoda added a commit that referenced this issue Aug 6, 2015
@arunoda
Copy link
Contributor

arunoda commented Aug 6, 2015

We'll do a release today :)
Thanks all.

@danielparas
Copy link

Hey guys, great work in adding IE9 support!

I'm testing it out on a test app I have locally however I'm not managing to browse from one page to the next by clicking on links as one would normally do when browsing. When clicking nothing happens.

It only works if I right click a link and select "open link" or "open link in new tab" form the context menu (i.e. tell the browser access the URL directly)

Are there any other packages besides tmeasday:html5-history-api that I need to install?

Packages I have installed:

  • arillo:flow-router-helpers 0.4.1
  • kadira:blaze-layout 2.0.0
  • kadira:flow-router 2.1.0
  • meteor-platform 1.2.2
  • tmeasday:html5-history-api 4.1.2

P.S. links generated with pathFor helper eg. <a href="{{pathFor 'blog' postId=_id}}">Link to post</a>

Thanks!

@arunoda
Copy link
Contributor

arunoda commented Aug 6, 2015

I think FlowRouter is just the base for IE9 support. You need to work on some other packages and your app for that.

@pahans
Copy link
Contributor

pahans commented Aug 7, 2015

@danielparas there was a issue with that PR. we have have fixed it now. can you try it on flow router 2.1.1?

@danielparas
Copy link

@pahans - working perfectly now! 👍

Thanks

@alanning
Copy link
Contributor

alanning commented Aug 7, 2015

Seems like there's a missing test for "click link == page changes".

Not sure if there's a way to test that with tinytest. Any interest in testing with Jasmine?

Cucumber would be best but I don't think it can be used to test packages, only apps. (Hope I'm wrong about that though.)

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

No branches or pull requests

7 participants