[Resolved] Brave form submission breaks homepage for all browsers

Home Forums Support Brave form submission breaks homepage for all browsers

  • This topic has 17 replies, 3 voices, and was last updated 1 year ago by David.
Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #1175944
    Brian

    My WordPress site – https://huppbrian.us – has a Ninja Forms contact form and a Soliloquy image slider on the home page. The site uses Generate Press Premium as its theme. When the contact form is submitted, it displays a brief confirmation message, and then redirects to the home page. Everything works fine using Firefox for Windows, Chrome for Windows, Firefox for Android, Brave for Android, and Chrome for Android.

    But after I submit the contact form from Brave for Windows the form generates the associated e-mails, and displays the confirmation message, but after the redirect, the Site Logo, and Soliloquy slider no longer render properly. The REALLY strange thing is that after Brave mangles up the home page, none of the other browsers will display the home page properly either.

    I’ve tried clearing the caches on all the browsers. The only thing that I’ve found that puts everything back aright is if I edit the home page, and then update it without making any changes using some other browser than Brave for Windows.

    I tried uninstalling Brave, downloading the latest Windows 64-bit installer, and re-installing Brave. But the problem persists. Frankly, I’d be willing to just kick Brave to the curb, and press on with my website development if Brave wasn’t breaking things for every other browser.

    For the time being, I’ve taken the contact form off of the menu, but you can still access the page at https://huppbrian.us/contact.

    I don’t know whether this is a browser, theme, or plugin issue. I have tried to submitted a support forum topic on Brave’s support community. The ball should probably be in Brave’s court, but the issue is serious enough to warrant a topic here. Brave is breaking my site for everyone. Is there any way for the form to check the user’s browser and disallow form submission from an offending browser?

    Brave Version 1.3.118 Chromium: 80.0.3987.116 (Official Build) (64-bit)

    #1176540
    Leo
    Staff
    Customer Support

    Hi there,

    Can we wait to hear from the plugin support first?

    I really don’t see GP being the issue here.

    Are you referring to this plugin here?
    https://wordpress.org/plugins/brave-popup-builder/

    It only has 100+ active installs and 2 reviews.

    Drag and drop builder often causes issues like this.

    Maybe try another popup plugin?

    #1177005
    Brian

    No. I’m not using that plugin. The issue is with the Soliloquy slider on my homepage. After submitting the contact form, Brave mangles the slider display for itself, and every other browser.

    I have seen talk on Solliloquy’s support forum about Soliloquy CSS conflicting with theme CSS. Could that be the issue? If so, how to fix?

    Another possibility is to detect that the visitor is using Brave, and if so prevent the form submission. How?

    #1177006
    Brian

    BTW – I tried disabling the Soliloquy and Ninja form styler plugins I’m using, but the didn’t fix the issue with the Brave browser.

    #1177724
    Leo
    Staff
    Customer Support

    I have seen talk on Solliloquy’s support forum about Soliloquy CSS conflicting with theme CSS. Could that be the issue? If so, how to fix?

    If it’s a conflict with the theme, then the issue should show before the submission of the form.

    Another possibility is to detect that the visitor is using Brave, and if so prevent the form submission. How?

    I don’t believe there is a way but you’d need to check with the plugin support.

    #1184240
    Brian

    So I just tried another experiment. On my staging site, I performed a GeneratePress customization reset. Then I used Brave for Windows to submit my contact form, et voila! Everything worked fine. Brave displayed the homepage after the form submission just fine.

    So it looks like my issue is with Brave’s interaction with GeneratePress and has nothing to do with the Soliloquy slider. I should have realized that, because the Site Logo was also being misrendered by Brave (and everyone else) after I used Brave to submit the form with all of my GP customizations in place.

    Got any suggestions for how I can troubleshoot further.

    BTW – For this test on my staging site, I had to take the reCAPTCHA out of the form, and none of the contact form e-mails get generated on the staging site. So in order to take these factors out of the picture, I’d have to do this test on my production site. I don’t really want to do that, but I can if necessary.

    #1184535
    David
    Staff
    Customer Support

    Hi there,

    are you able to replicate the problem again ? And if so once the issue has occurred can you Right Click > Inspect the page and tell us if there are any red errors in the Console.

    #1184839
    Brian

    Yes. I’m seeing GET errors for all the images on the page…

    2 JQMIGRATE: Migrate is installed, version 1.4.1
    (index):366 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/plugins/soliloquy/assets/css/images/preloader.gif 403
    (index):212 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/uploads/2020/02/Site_Logo.jpg?time=1583333033 403
    (index):258 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/uploads/2020/02/WhatsHupp-2.jpg?time=1583333033 403
    BriRants-2.jpg:1 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/uploads/2020/02/BriRants-2.jpg?time=1583333033 403
    Image (async)
    (anonymous) @ (index):454
    each @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    each @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    (anonymous) @ (index):454
    i @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    fireWith @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    ready @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    J @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    Huppstead-2.jpg:1 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/uploads/2020/02/Huppstead-2.jpg?time=1583333033 403
    Image (async)
    (anonymous) @ (index):454
    each @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    each @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    (anonymous) @ (index):454
    i @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    fireWith @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    ready @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    J @ jquery.js?ver=1.12.4-wp&time=1583333033:2
    Huppiary-2.jpg:1 GET https://secureservercdn.net/198.71.233.129/egt.f49.myftpupload.com/wp-content/uploads/2020/02/Huppiary-2.jpg?time=1583333033 403

    #1184859
    Brian

    Aaarrrggghhh!!!
    I just tried resetting the GeneratePress customizations on my production site, and then used Brave to submit my contact form. After the post-submission redirection, none of the images are loading. I thought I was onto something when resetting the customizations fixed the problem on the staging site. Back to the drawing board.

    #1184865
    David
    Staff
    Customer Support

    Can you try disabling your CDN ?

    #1184909
    Brian

    Okay. I’ve done a bunch of experiments. I don’t think this has anything to do with GeneratePress, Sililoquy, or Ninja Forms. I thought maybe Brave wasn’t tolerating the post-form-submission redirection, so I took it out. But Brave still breaks all site image retrieval from any browser after form submission.

    #1185299
    David
    Staff
    Customer Support

    Might be worth speaking with your host to see if any server related errors can shed some light on this.

    #1185331
    Brian

    Yes absolutely. I got GoDaddy on the horn a few hours ago, and demoed the issue with them. They didn’t see anything amiss, and suggested I open up an issue with the Brave browser community. I did, and they were able to reproduce the issue, so they’ve taken up the gauntlet. I think we can probably close out the GP support ticket for now. Thanks for looking into it, but it definitely looks like a Brave problem. Pretty scary that a browser can mangle up site rendering for other browsers, though. I thought maybe Brave was changing something on my local machine, but when I demoed the issue for GoDaddy, they saw the symptom as well. That means Brave is somehow getting into the server, and that’s even scarier.

    #1185346
    David
    Staff
    Customer Support

    Wow that is rather scary! Thanks for the heads up – be interested to hear what you find.

    #1192421
    Brian

    Okay. I have a workaround.

    The issue is with Brave’s interaction with the Site Logo in the Generate Press theme. I verified this by taking the Soliloquy slider completely off the page and replacing it with some static tile images that are clickable.

    When the logo image is configured, after any of the forms on the site (post responses or contact form) from Brave for Windows, the site logo is no longer displayed by any browser, however the alt text associated with the logo image is displayed. When the logo element is examined the console shows that the browser is returned a 403 error by the server.

    As a workaround, I took out the logo entirely, and added a custom HTML widget to the page/post header in its place. The replacement “logo” is of the form [site logo image]</img>. I took out as much styling as I possibly could for this hyperlink and everything works fine from all browsers. The only compromise is the the Generate Press header widget area is on the right, and I’d prefer to have the “logo” on the left. But that’s a small price to pay for not having the possibility that a visitor’s browser might break rendering of the header for all browsers.

    There’s something about the CSS that Generate Press puts onto the logo that Brave doesn’t like, and somehow Brave is somehow able to pass that aversion on to other browsers. I’m still unsure exactly how Brave is doing that, but for now I’m satisfied with the workaround.

Viewing 15 posts - 1 through 15 (of 18 total)
  • You must be logged in to reply to this topic.