Hi! I've come across a strange issue and wondered if you experienced similar behav

Just a quick note - thanks for the detailled deion of what you're experiencing.<

I think it was <style>...</style> <strong

Hi Woeps! Thanks, too, for the rapid response. <div class="snipp

This sounds great! In my use-case: all inlin

Delta-Files not loading correctly on iOs using 3G about ajaxify HOT 21 CLOSED

arvgta commented on May 18, 2024

Delta-Files not loading correctly on iOs using 3G

from ajaxify.

Comments (21)

arvgta commented on May 18, 2024

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?

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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.

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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...

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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?

from ajaxify.

woeps commented on May 18, 2024

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!

from ajaxify.

arvgta commented on May 18, 2024

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...

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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.

from ajaxify.

woeps commented on May 18, 2024

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! 😄

from ajaxify.

arvgta commented on May 18, 2024

Hey Woeps!

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

http://4nf.org/ajaxify.js

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:

http://4nf.org/more/thanks/

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

from ajaxify.

woeps commented on May 18, 2024

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

from ajaxify.

arvgta commented on May 18, 2024

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!

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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?

from ajaxify.

woeps commented on May 18, 2024

Looks like you're good to go. 👍

Works like a charm in my case.

from ajaxify.

arvgta commented on May 18, 2024

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:

http://4nf.org/interface/

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

Cheers!

from ajaxify.

woeps commented on May 18, 2024

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.

from ajaxify.

arvgta commented on May 18, 2024

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...

from ajaxify.

Delta-Files not loading correctly on iOs using 3G about ajaxify HOT 21 CLOSED

Comments (21)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Jobs