Share Button Crashes Browser

Given that this is still happening and many are also mentioning that they are experiencing it with the Facebook share, can someone please advise as to what is going on and why the browser crashes when you click on Facebook share button? Please? If I can’t resolve this to the satisfaction of knowing I am not causing my visitors to keep crashing, I have no choice but to disable it and I so far like it for the most part.

We have not heard any reports of this kind. In either case, if *your browser* crashes after you access Facebook, then it means there’s an issue with the Facebook sharer page that conflicts with your browser.

The plugin simply redirects you to FB, after that it has no more control, any crash is specifically due to the browser, possibly a browser extension you are using. You can try disable extensions, or a different browser or have your friends test with Chrome and see if they can reproduce.

It has something to do with the way the script is generating the link’s values, they are not formed the same as the ACTUAL facebook sharer and that’s probably the cause, maybe you are done with it when it goes to the new tab but what you fed into the line comes from you and its somehow causing a crash in the browser.

I have confirmed it happens nearly all the time if you click on the share button without hovering over it. But when you hover over it and wait for it to actually generate the link, which seems to be delayed – maybe due to styling and animation delays, then when the link expands to the entire width of the browser’s status bar, then you click, it will work, except for some exceptions still.

I have also done it on a browser that is a clean profile on Chrome of the same version and Dragon of v49 and while it happens less in 49, it still happens half the time. SO no, I am fairly certain it has nothing to do with my set up and that something fed into the URL is causing the browser to throw an exception during rendering.

Either way, since you don’t see a problem and it means you won’t do anything, I have to just remove it and find another solution, this is the ONLY social share plugin that has EVER done this, too bad, the search continues.

We don’t generate the link on hover, the link is generated server-side when the page is first generated by WordPress (and before it even gets sent to the browser). So, if anything happens during hovering that is trying to change the link, than that is caused by something else. Unfortunately without a link to the site or knowing your setup it’s difficult for me to do anything.

Ok let me be blunt, YOU ARE crashing it based on how you are feeding the data, here is an example of WHY you are crashing it and YES, YOU are crashing it.

This is what FB Sharer does with the post:

https://www.facebook.com/sharer.php?u=https%3A%2F%2Fmajormike.us%2F2016%2F05%2F14%2Fa-historical-day-122%2F&t=A%20Historical%20Day%20%E2%80%93%20Major%20Mike%27s

Yet, this is what YOU are pushing into the URL bar:

[Large code excerpt removed by moderator per forum rules. Please use the pastebin for all large code excerpts. It works better anyway.]

SO explain to me how you are not generating anything that is causing the problem?

Now to demonstrate it even more bluntly, I am going to quote it instead of code formatted, so you can see the SHEER amount of data you are shoving in a URL bar which is overloading its limits. Its unnecessary and extremely poorly implemented.

[mod edit: verrry long link removed as it was causing forum issues]

You have to understand that any plugin you have on your site, as well as any piece of JavaScript your themes/plugins load, might be affecting the URL. Our plugin simply passes in the information the sharer needs, something else must be affecting this behaviour but without a link to a page where we can investigate the issue it’s impossible for me to tell what is causing it.

I think you are not trying hard enough given that the url data I provided as the link to the site on it if you actually looked.

The plugins is pushing all this data to the URL overloading the browser and there is NOTHING else that is doing this. You are trying to send everything which is unnecessary if the OG data is set properly, you don’t need to be pushing everything, including encoding the image to push it with the URL, none of that is required and none of that is expected from sharer as seen by what data THEY actually send.

So anything more is a stability issue and has nothing to do with anything else on my site, if I disable EVERYTHING but your plugin, this still happens and while no one wants to admit they are doing something that can cause problems, you need to stop passing the blame and actually look and see why its happening.

I showed you what the FB sharer sends to the URL, and what your plugin is sending to the URL, there is no magic here. The cause and effect is established without any doubt, except you don’t want to even entertain the thought.

Sorry, I just noticed that they removed the code block containing the information, that’s not right, it is inside a code block for a reason.

Anyway, get it here: removed_content.txt

The plugin tries to send an image associated with the post. It first attempts to use the featured image set for the post, if that’s not available then it simply pulls in the URL of the first image it finds in the post (based on the src attribute).

What’s happening here is that the first image in your post linked above has a so called “data” URL in the src attribute, this is a special type of URL that provides the data for the image instead of a link to the image. So either edit the post to make sure the image URL points to the location of an image instead of its data or set the featured image for the post so the plugin will pick that up instead.

It looks like all the images in that post use this type of URL. I strongly recommend changing them so that the URL points to an image location on your server as this kind of URL you are using is not very web friendly and should generally be avoided.

That is not proper handling. You should not be grabbing or sending anything to the sharer because the person puts that in the OG:image so it will pull it on its own, you have no need and SHOULD NOT be sending ANYTHING specifically or explicitly in the share URL, all that you need to send it the URL of the page and that’s it.

The title = OG:title
the content = OG:url (also the url you are sending)
the image = OG:image
the video = OG:video

you should not be sending ANYTHING to the url beyond the required initiator of the URL for the site. If the end result is malformed, its the fault of the user for not properly structuring their post to contain the data.

You want to do the work for THOSE users, fine, go ahead, but at least provide an option for those of us who handle it properly and don’t need the unnecessary idiot proofing of sending the whole kitchen sink with the url killing the browser.

You MOST CERTAINLY should at least be checking that the data you are shoving in the image portion is not a gigantic data:uri, that’s just common sense. You can argue that it checks for picture, then grabs the first one and all that but its moot with og:image and you should be respecting that and even if you don’t respect that and want to shove that information in the URL, don’t do it with the entire encoded content of the data/uri

You should either leave it up to the user to properly configure the open graph data for proper shares, or provide an option for those who have done that as to avoid this stability nightmare and overreach by skipping it and sticking to sending the ACTUAL core share data that FB send itself. You can add the added whatnot for others but the all or nothing approach you are taking is unstable and you should see that.

Final thoughts, I appreciate your recommendation to avoid using data:uri but the fact is that images smaller than a certain size have a better SEO+load performance as data:uri, so while I appreciate that it cuts down on you doing it right and saves you the hassle, its not a good recommendation and I will ask that you make your plugin work right in spite of how the user does things, not in place of it.