Forms not working anymore in macOS Firefox (latest)

[tchapi]

Hi

I have an ajaxified page with a simple POST form. In macOS Chrome, it's working fine (ajaxify posts the form, gets the response, displays what it should). On macOS Firefox, ajaxify does what it's supposed to do, BUT the page is reloaded anyway (another GET is issued).

How can I mitigate this issue ?
Thanks a lot !

[arvgta]

Hi Tchapi,

thanks for pointing that out! I have forwarded it to the guy who debugged the last version.
Hope he responds soon...

(it reads as if it were specific to the latest version?)

EDIT: Works on Firefox for Windows 10 against 4nf.org and another test site - however, these employ GETs

Thanks and regards,
Arvind

[tchapi]

Thanks. I don't know if it's specific to the latest version, but the exact same site has different behavior on both navigators, and it wasn't this way before, hence my issue...

[arvgta]

Alright - thanks. We'll see what the other guy says... I'm off for the evening - please don't be irritated.

[edito]

Hi @tchapi,

I'll need some additional information about your website preferences for ajaxify and form data that is sent to the page because I couldn't reproduce your issue on Firefox for windows (for both types of request POST/GET).

My current opinion is that it's not related to POST/GET type of request, also have something else on my mind, could you please try the testpatch branch ajaxify file from this link on your development environment and tell us if it behave the same or not?

[tchapi]

Hi and thanks for your answer

I tested with your version but it's the same : Chrome OK, FF NOK.

Here is my config :

$('#content, #my-account, #my-account-mobile, #site-navigation, #csrf-token').ajaxify({
    prefetch: false, // Plugin pre-fetches pages on hover
    canonical: true,
    scrolltop: true, // always scroll to top
    bodyClasses: true, // Copy body classes from target page, set to "true" to enable
    cb: function (error) {
      $('#menu-toggle, #site-header-menu').removeClass('toggled-on')
      $.cache1('f')
    }
  })

The form is extremely simple :

<form method="POST" action="http://localhost:8002" accept-charset="UTF-8" enctype="multipart/form-data">
  <input name="_token" type="hidden" value="ZWJrhCB2OneyGhCpRgFdfrpzhNTGVBHtniAjgMs6">
    <input name="given_name" type="text">
    <div><input type="submit" value="Save"></div>
</form>

When inspecting the two behaviors, the only difference I see is that on Chrome, once the POST comes back with a 302 redirect, Chrome goes fetching (GET) the redirection target without specifying a content-type in the request. On the other hand, FF explicitely specifies "application/x-www-form-urlencoded" as content-type in this GET request, and that may trigger an additional GET afterwards ?

I'm a bit lost ...

[arvgta]

Hi @tchapi,

just my fifty cents:

prefetch: false

has be changed to

prefetchoff: true

in the latest versions

... in order to compare apples to apples.
But even if it works with prefetchoff set, it would still be a bug, because your use case should work with prefetch enabled nevertheless.

[edito]

Hi again,

too many questions is passing through my mind. I would like to know if everything works fine on windows firefox browser for your website. To be sure that it's a specific platform&browser issue.

Next thing, I'll recommend you to find this line (264) in latest version
if (!pre) location.href = hin; //If not a pre-fetch -> jump to URL as an escape
and comment it out. Then check if it still does refresh (please make sure you cleared browser cache after commenting line).

One more thing, I'll recommend you setting memoryoff: true, instead of flushing cache with $.cache1("f") on every request.

[tchapi]

Alright, with the if (!pre) location.href = hin; line commented, it works on Chrome and FF (and Safari, too)

Digging deeper, I have the impression that Firefox gets the response base64-encoded (whereas Chrome / Safari does not). I don't see which header would trigger this, but this is what could trigger a false in _isHtml(xhr) on this specific line ?

[edito]

Hi,

ok, we found the source of the issue. However I would like to be sure that everything works fine on windows platform browsers for your particular case, if it's possible, to know is it a platform related issue without some hidden bugs.

Since I'm not great with writing those header checks, I would like to hear what @arvgta has to say about it.

[arvgta]

Hi @edito,

thanks for all your efforts and finding the line that was causing this issue.
I agree that a test on Windows browsers would be useful.
Unfortunately, I am no better than you on these header checks.

@tchapi : It would be interesting for the records additionally, to know whether turning off prefetch before commenting out that line with:

prefetchoff: true

...made a difference?

Thank you both!

[tchapi]

I tested a bit more :

• prefetchoff: true makes no difference
• I tested on a virtual Win 7 machine : exactly the same behavior than on the macOS host : Chrome OK (all cases), FF OK only if line commented, else NOK

[arvgta]

@tchapi

Ok, thanks, very interesting! But when commenting out the line:

if (!pre) location.href = hin;

...it works on all browsers, right?

[tchapi]

That's exact

[tchapi]

A fix would be to allow x-www-form-urlencoded in the isHtml() function, but while this will work in my case, I'm not sure it doesn't have other implications ...