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

Delta-Files not loading correctly on iOs using 3G #19

Closed
woeps opened this Issue Apr 28, 2014 · 21 comments

Comments

Projects
None yet
2 participants
@woeps
Copy link

woeps commented Apr 28, 2014

Hi!
I've come across a strange issue and wondered if you experienced similar behavior or might have a tip, where I should look for to resolve this:

I'm using ajaxify on a site, to (re-)load the whole (content-div) container asynchronously. The "Delta-Files"-Functionality works like a charm: Different Views (Position in the navigation) have different style sheets and some may require an additional js, which is working fine on most (modern) OS/Browser-Setups.

But on iOs (Safari) it seems like the css-files won't get loaded (or at least they don't affect the output), when the iPhon/iPad is connected to the internet using 3G.
If it's connected to my (home/work)-network using wifi it works like it's supposed to be. (local dev-Server AND external hosted)

I also checked using the iOs-Safari debugging console, but no errors occur, just the usual "Ajaxify loaded..."-notice.

Any ideas on this would be very much appreciated, thanks.

P.S.: Apart from this I ran into some troubles when a view loaded per ajaxify contained some javascript which should be triggered using document.ready: The js got executed before the additional css got loaded. - But I found my way around this. :)

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented Apr 28, 2014

Just a quick note - thanks for the detailled description of what you're experiencing.
However, I have no idea so far. You said it happens on iOS only when using 3G, no error in the debugging console and it even works when using WiFi (on iOS).

So, without wanting to be defensive, it could be a funny of iOS, caching in iOS, or how iOS handles 3G connections.

Sorry, but I have no idea how "Ajaxify" could be causing what you described.

Has anyone else something to say about this issue?

@woeps

This comment has been minimized.

Copy link

woeps commented Apr 28, 2014

Thanks for your fast reply!
Of cause it seems like a platform-specific bug and not directly caused by your plugin.
But I don't have any clue what to do with this at the moment, so I thought maybe somebody else experienced something similar and could provide a suggestion where to look?
I'll try to investigate further in this and will post back if I find some new clues.

At the moment my best guess is iOs-Safari could not like the way stylesheets get attached to the existing dom.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented Apr 29, 2014

Hi Woeps!

We'll definitely leave this issue open for a while, for others to comment on.
I'm clueless as well.

Just for informative purposes, the CSS's are dynamically injected into the head with:

$("head").append(...)

which I believe is alright.

@woeps

This comment has been minimized.

Copy link

woeps commented Apr 29, 2014

Just a short update, what I could verify:
I checked this issue with a couple of devices today and it seems to be really specific only for iOs devices, which are using their mobile-data-connection (3G/EDGE).
The new stylesheets which should be loaded on the new request just won't get applied to the rendered view.
Using the wifi-connection on the same device lets the issue disappear.
Turning off javascript (or disabling ajaxify) won't load the content asynchronously, but when the whole page gets loaded and rendered everything is fine - no matter of the connection-type.

Though Opera-Mini has its own drawbacks, at least it seems to render the views the right way, no matter of the connection-type.

@woeps woeps closed this Apr 29, 2014

@woeps woeps reopened this Apr 29, 2014

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented Apr 30, 2014

Hi Woeps,

thanks for the update!

Just an idea - could it have to do with browser caching?

We'll leave this issue open for a while...

@woeps

This comment has been minimized.

Copy link

woeps commented Apr 30, 2014

So my next step was monitoring the iOs Device accessing the site using the WebInspector.
It looks like it could be some kind of a process of safari which tries to make the download faster:
On Wifi: All linked resources (scripts, stylesheets) get loaded by an additional request and referenced, like it's supposed to be.
On mobileNet: WebInspector presents all resources as inline-elements in the head (html tag). OnClick Ajaxify makes the new request and downloads the new file (again all resources are presented as inline-elements).

So my thought is: I know ajaxify's Delta-Files-Function works great, but would it be capable of replacing (or adding) inline-stylesheets as well or could this create some pitfalls?
It seems there is a method of iOs involved to speed up the download (minimize the number of requests) which is possibly screwing up the DOM. (need to investigate more)

I'm sorry if this is too much (not quite useful) information ("Spamalert" 😛 ), but I thought I'd post every piece of information I gather in the process of investigating in this issue. Maybe there comes a point where somebody can put the dots together and has some more information or tips.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 1, 2014

Thanks for the very detailled report!

That's not spamming, just working very thoroughly.

It seems that during mobileNet the files are serialised to inline stylesheets to save GET's....
Does this only apply to

 <style>...</style>

tags in the head?

Are there other tags than "style" affected?

So moving towards a solution, and if it's only inline "style" tags that are affected I would add the following logic to "delta loading":

  • (Re-)load all inline style tags in the head

Would be interesting to hear what others think?

@woeps

This comment has been minimized.

Copy link

woeps commented May 1, 2014

I think it was <style>...</style> and <script>...</script> which were put into <head>...</head> as inline elements.
I will do some further testing later on in the afternoon. (To see which tags are affected exactly and if altering the inline stylesheets using js is getting the results I'm hoping for.)
Will update you if I got some results.

Thanks a lot for your help!

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 1, 2014

Hi Woeps!

Thanks, too, for the rapid response.

<script>...</script>

tags should be getting re-fired provided inline is set to "true" (which is default).
So, you should be able to workaround it that way. An interesting test-case.

However, that is not the most elegant solution, and you are not the first person asking to extend the plugin to handle

 <style>...</style>

tags...

If desired, I think I know how to amend the jQuery code accordingly and I don't think that will make the code explode in terms of footprint, because I can re-use some parts of the delta-loading mechanism.
I think it's just a matter of a few lines of code.

I have the impression, this issue potentially affects quite a few users, some of them surely expecting these "style" tags to be handled correctly.

Before I code these extra bits - can we agree on the following rules?:

Affected are:

  • Inline "style" tags, in the head only
  • They should be fired every time - like inline "script" tags, without checking for their contents.

If we can agree on these simple rules, I would proceed to coding...

Most of all, I need to know whether the "style" tags are only to be handled in the head, which would be the simplest case, or also should be handled in e.g. the content being swapped, which would require more care...

@woeps

This comment has been minimized.

Copy link

woeps commented May 1, 2014

This sounds great!

In my use-case:

  • all inline style tags are only found in the head
  • The data gets (down)loaded anyway and if the stylesheet's content doesn't change, there is no harm done by actualizing these contents. If the content differs from the previously loaded, it changed for a reason and should get presented on the page anyway.

Which means: I can definitely agree to your rules.

But you may think about building this functionality with another flag/option to enable/disable it for different use-cases (apart from the delta-FILE-loading). - If that's not too much work. - I think this would give the most possible options to use the plugin's function.

I did some testing again and it looks like this functionality would resolve my problem. (actually just the symptom, not the real reason behind the requests getting serialized - but still it would solve the issue fine!)
Though I still couldn't narrow down where the data actually gets serialized. I tested it on 2 different Servers and my localhost Dev-Server which I reached over Lan (wifi) and Wan (3G/EDGE). I encountered my Problem only on the 2 "real Servers" - not on my localhost. It looks like there is much more in the mix, than I can get a hang of.

Edit: I already used inline: true, working great. Just didn't really thought about it by the time I answered.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 1, 2014

Hi Woeps,

that is great news and will probably apply to quite a few users of the plugin.
I will code and test tomorrow.

Hopefully, this change request will take care of the 2 mysterious "real Server" problems, too.

@woeps

This comment has been minimized.

Copy link

woeps commented May 1, 2014

Nice, thanks!

It should definitely resolve my problem, 'cause using the debug-console for triggering jQuery-functions, which change the inline style's content directly, take effect immediately. (In the test I used something like $('style').eq(0).html('body{background-color:#000000;}') successfully.)

Looking forward to test your genius code! 😄

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 2, 2014

Hey Woeps!

Have implemented a draft version that seems to be working.
Only this file has been modified:

The following logging message is left active and should show the contents of any "style" tags being injected:

 $.log("Adding style tag: " + t);

Please test asap, because I would like to push all the files and publish a new release, if successful...

Thanks very much!

PS: I'd like to add you to this page:

Do you have any URL that you would like to push?

@woeps

This comment has been minimized.

Copy link

woeps commented May 2, 2014

wow, that's fast! - Sure I'll take it for a test-ride right away!

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 2, 2014

Hi Woeps!

I've pushed https://github.com/arvgta/ajaxify/blob/new/ajaxify.js, too.
But the minified versions are old still - please don't use them...

Thanks!

@arvgta arvgta added the enhancement label May 2, 2014

@woeps

This comment has been minimized.

Copy link

woeps commented May 2, 2014

At first sight, it works great!
But I found, that (at least in my case) the inline-css gets added (appended) to the end of the head on every request.
If the page would have two inline-style elements and gets (re-)loaded by ajaxify 3 times the dom will end up with 8 inline-style elements. If the definitions even differ, it ends up in a kind of mess.

I'd propose to remove all inline style elements in the head before adding the new ones.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 2, 2014

Of course - sorry about that.

Now erasing the existing style tags before inserting new ones...
(code in ajaxify.js pushed again)

Could you re-test, please?

@woeps

This comment has been minimized.

Copy link

woeps commented May 2, 2014

Looks like you're good to go. 👍

Works like a charm in my case.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 2, 2014

That's great! A potentially major improvement - thanks very much!

I will push minified versions shortly and create a new release.

Do you have any URL for the "Thanks" page?
Also, if you have a showcase, I could add you on this page:

I don't supppose "meta" tags need this kind of attention?

Cheers!

@woeps

This comment has been minimized.

Copy link

woeps commented May 2, 2014

I don't think meta tags would need this functionality.
One of the major reasons for using them is for search-engines, which normally (as far as I know - and this is way off my competence) won't use js, so it would be important to still have a compatible no-js version running.

I don't have any personal website running at the moment. - But all the credit is due to you anyway!
I'd be happy to provide you with a showcase, but it's gonna take around a week 'till the project goes live. I'll send you the url, when it's public.

Thanks a lot for your fabulous work on this great plugin!

I guess we can close this issue now.

@arvgta

This comment has been minimized.

Copy link
Owner

arvgta commented May 2, 2014

Thanks to you, too! Most people traverse the web rapidly without giving feedback, like you did.
Yes, please do provide a URL to the showcase once you're ready.
A week is no time at all, no problem.

I'm just asking you, because I'm asked quite often, what kind of demos I can provide, that use the plugin. The more the merrier :-)

The plugin has grown so much lately, that its usage is not as trivial as it once was and therefore up-and-running showcases are great also for illustrative purposes...

@arvgta arvgta closed this May 2, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment