|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66371 JavaScript (I think) causing error on all pages
Submitted: 2013-12-31 06:04 UTC Modified: 2015-01-11 08:57 UTC
From: TygerGilbert at USAWebAdv dot com Assigned: Unassigned (profile)
Status: Closed Package: Website problem
PHP Version: Irrelevant OS: WinXP w/IE-8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: TygerGilbert at USAWebAdv dot com
New email:
PHP Version: OS:


 [2013-12-31 06:04 UTC] TygerGilbert at USAWebAdv dot com
This problem appears on almost every page of the docs for me. 
The page takes several seconds to load, then an error dialog pops up saying: "Stop running this script? A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer might become unresponsive. [Yes] [No]  

Selecting [No] causes the error dialog to go away but immediately pop up again.

Selecting [Yes] allows the page to finish loading and lets me continue reading the page without an error.

After selecting [Yes], the "up arrow" in a circle in the bottom right corner appears, so I think the script that creates that floating link is probably causing the error, or something else right before it. What used to be the left submenu of other funtion names now takes up the entire top of the page, with horizontal lines running across it and one function name at the left between the lines. The function desciption and all other instructions appear below it.

Running in "Compatibility Mode" prevents the error dialog from appearing, but the reader comments at the bottom of the page fail to appear. The space for them still appears, but no text.

Switching out of "Compatibility Mode" shows the comments at the bottom, but the error dialog appears again each time I select a different page or reload the current one. This is maddening. 

For several days this month, the site was loading so slowly that it was almost useless. I would click a link and then go get a can of soda, and when I returned, it often still hadn't displayed the page.

The number of problems I am experiencing with the "New, Improved" page design make me want to return to the old page design that didn't have all the (useless to me) new bells and whistles, but WORKS, and without the slow response and errors. Is that still possible?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-12-31 07:13 UTC] a dot tromp at plusine dot com
I experience the same problem. However, it depends on which site I'm being routed to. For example, page gives the mentioned popup. Page does not. I hope this helps troubleshooting this problem.
 [2013-12-31 07:39 UTC] TygerGilbert at USAWebAdv dot com
A dot tromp, I get the same response to the links you provided (popup on one but not the other). The URL I'm using when I get the problem is
 [2013-12-31 09:19 UTC]
-Type: Documentation Problem +Type: Bug
 [2013-12-31 09:19 UTC]
nl1 has been disabled for the passed few days due to other issues.
Does this only happen in IE for you guys? (I can't reproduce this on other browsers, and don't have Windows)
 [2013-12-31 16:13 UTC] TygerGilbert at USAWebAdv dot com
Bjori@: Yes, I just now tried GoogleChrome and Mozilla Firefox to confirm, and neither of them showed an error dialog, and both of them displayed the link list on the left correctly. IE-8 shows the link list at the top full width and the documentation full width below that. In "Compatibility Mode," the error dialog does not appear. When not in Compatibilty Mode, the error occurs on every page (that I have tried) in the function list. The page layout is the same (wrong) regardless of being in Compatibility Mode or not. 

For example, the error dialog appears when I go to: 

I must use WinXP because certain programs I use that are critical to my work do not function in Win-7 or Win-8 and no updates for them are available. IE-8 is the latest that is compatible with WinXP, so I can't update it. Using Chrome or Firefox is an option, but I prefer IE. Switching browsers just for PHP docs would leave me feeling annoyed with the site everytime. (This is irrelevant to fixing the error, but explains why I don't just change browsers.)
 [2013-12-31 20:12 UTC]
-Status: Open +Status: Feedback
 [2013-12-31 20:12 UTC]
Does IE have any sort of debug capabilities?
This is a complete guessing game unless we can narrow it to the actual file/function that is causing this issue on IE.

...On that note, I did notice 2-3 syntax things that _could_ maybe cause problems in IE..

Could you try again in about an hour?
 [2013-12-31 21:33 UTC] TygerGilbert at USAWebAdv dot com
-Status: Feedback +Status: Open
 [2013-12-31 21:33 UTC] TygerGilbert at USAWebAdv dot com
Yes, it does. I went to Tools menu and turned on Developer Tools. A new frame opened up at the bottom. I set Debug on and ran the page script again. Another window opened up with the source in it. Trouble is, I have no idea what I'm looking at, or what I'm looking for right now. The left frame showing the script has a BIG blank area starting at line 256 (a <div class="partintro">...</div>) and going to line 851 (<h2>Table of Contents</h2>...), and there are no other large blank areas. This was after I selected [YES] to the "Do you want to stop..." dialog box, so maybe this was where the script that was terminated was located. When I select [No] to allow the script to continue, the dialog box immediately reappears. I'm sure this is of little help, but that's the best I can do. This is out of my area of expertise now. 

I just tried the page again (14:30 MST) and it still produces the error box.
 [2013-12-31 22:09 UTC]
That big blank area is normal. Its generated markup and we don't normalize the space.

I'm out of ideas if those syntax changes I did in the js didn't make any difference, so we'll need someone on Windows to debug this.

Unfortunately, I don't know of anyone :(
 [2014-01-09 01:05 UTC] cmbecker69 at gmx dot de
I can confirm the issues regarding IE 8.  After stopping the script,
the error console reports "Process aborted in typeahead.min.js line 7
character XYZ", where XYZ has different values (e.g. 298, 633, 6762).
This happens apperently independent of whether I try to continue script
execution several times or not.  Especially character 633, which is 
inside the header of a for loop, is reported quite often.  
Unfortunately, it doesn't seem to be possible to debug minified 
JavaScript files in IE 8, as it is not possible to prettify them 
(to be able to set a break point for the appropriate statement).

However, I have some doubts that supporting IE 8 is necessary for  While I do understand that IE 8 is still in widespread 
use, I also do understand that it is an ancient browser (even if 
it was released in 2009) with a whole bunch of security issues.
IMHO no developer should use it nowadays to surf the web (for
whatever reason).

BTW: the site has a conditional comment to include Remy Sharp's HTML5 
shiv for *all* IE; that is most likely not *necessary* for recent 
versions (at least IE 11 is perfectly capable of handling HTML5, and 
even IE 9 might be).
 [2014-01-09 01:16 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2014-01-09 01:16 UTC]
Someone mentioned typeahead.js being a problem somewhere else too..
Maybe that plugin just doesn't like IE8? Adam.. Could you check it out?
 [2014-01-09 07:29 UTC] TygerGilbert at USAWebAdv dot com
cmbecker69@, IMHO it doesn't matter what browser a developer uses to browse the web. It's the users who matter for ANY website, and since there is still a large number of users who still prefer IE-8, a site shouldn't break for them. I think it's called "backward compatibility." I understand that most users of the site are developers, but if anything, I think that would make it even more important that be the model of compatibility and ease of use in its entirety, particularly since there is no alternative site available. Letting the site behave badly for some older browsers just isn't a good example to set. Maybe I'm too sensitive to the idea of abandoning them because I'm an "old browser" myself at 65 now, but I'm still capable of providing an insight into the attitudes of a that large body of WinXP/IE-8 users who just won't go away yet. That insight can be carried over into a lot of other websites for the developer who is wise enough to listen. Fancy JavaScript functions and exotic page behavior can often be more of detriment to easy use than a benefit.
 [2014-01-12 03:28 UTC]
It appears the problem exists in typehead.js and only effects IE8 users, as far as I can tell. I managed to track down the patch from twitter/typehead here which details the issue found in PR 457 here

Currently this PR has only been merged, but no release was made since 0.9.3, so we can either patch it manually or wait for the next release to update typehead.js

It's a simple fix anyway.
 [2014-01-12 05:48 UTC]
-Assigned To: aharvey +Assigned To: googleguy
 [2014-01-12 05:48 UTC]
Patch it please.
 [2014-01-12 06:31 UTC] TygerGilbert at USAWebAdv dot com
Yea! Thank you GoogleGuy and Bjori! I will wait with baited breath (breath that smells like fish bait) to see the results of your great work!
 [2014-01-14 10:55 UTC]
Automatic comment on behalf of googleguy
Log: Patching typeahead.js to fix bug #66371
 [2014-01-14 10:55 UTC]
-Status: Assigned +Status: Closed
 [2014-01-14 16:54 UTC] TygerGilbert at USAWebAdv dot com
Uh, I'm still getting the error.
 [2014-01-14 17:36 UTC]
You likely will need to clear your browser cache for changes to take effect.
 [2014-01-14 18:52 UTC] TygerGilbert at USAWebAdv dot com
I cleared the cache, closed the browser, reopened the browser and went to the functions. Still a delay, after which the error dialog box again appears. The formatting is still off, too, as the left menu is at the top.
 [2014-01-14 22:11 UTC]
-Status: Closed +Status: Re-Opened
 [2014-01-14 22:11 UTC]
Can you screenshot the formatting?
That seems like unrelated issue, but just to confirm it would be nice to see.

As for the javascript fix, it takes time to roll the fix to all mirrors and clear various caches and headers.
Although we do attempt to purge your local cache by attaching the last modification time of the files, we cache the .php pages also for a long long time - which means your browser may not have realized externally referenced resources had changed.
 [2014-01-14 22:52 UTC] cmbecker69 at gmx dot de
I can confirm Tyger's latest report.  I have cleared the browser cache,
disabled caching altogether and get the updated typeahead.min.js, starting
  (function(c){var l="0.9.3";

The IE 8 debugger stops execution sometimes in typeahead.min.js and 
sometimes in jquery.min.js (different positions).

Regarding the layout: it seems to me the issues in IE 8 are caused by
important style rules (float and width of .layout-menu) that are only 
available for @media, which is not recognized by IE 8.  Adding these 
rules to .layout-menu directly (via the developer tools) is putting 
the menu to the left; however, it doesn't look as in "modern" browsers.
I can't do screenshots now, but I'll make good for it as soon as 
possible (if still necessary).
 [2014-01-15 00:07 UTC]
Ok. I looked it up.. IE8 is as old as say FireFox 3.6.28, so the importance of supporting it is in the "if it works, it works - if not, doesn't matter" class.
I'm sure someone has a workaround for the @media not working on IE8 issue.

As long as that does not impact anything at all then we can apply that workaround I guess.

When you go to for the first time without cache... Is that the same error as when you click a link, or hit refresh?

This could be a issue with your localStorage, as we ship a lot lot lot of data to your browser for local storage the first time you come to
Then subsequent pages and refreshes try to short-circuit that request and use your browsers localStorage... that seems like a likely candidate for problems in very old browsers.
 [2014-01-15 00:44 UTC] TygerGilbert at USAWebAdv dot com
It sounds like you guys are guessing and don't have a clue as to what is actually causing this error, or how to fix it. I have a screen shot of the bad formatting, but this form doesn't seem to have a field to upload it or any other way to attach it, so I'm not sure what to do with it. Bjori, I understand your attitude about not spending anymore time on this. It makes sense. 

Regrettably, I'm hearing "The equipment and programs you use (and you, yourself) are too old, so your problems don't matter to the rest of us," or something similar all too often. Much of the world, particularly the younger "leading-edge" individuals, believes this way. You have to, or someone else will beat you to the finish line. And those of us in the back of the pack eventually get totally disqualified if we can't keep up or take too long even getting to the finish line. That's reality, and I accept it. I have to. I do appreciate everyone's time and efforts to solve this. Thanks! Just remember me decades from now (or sooner) when you are faced with similar difficulties, as you likely will.
 [2014-01-15 02:12 UTC]
Could you upload the screenshot to or something along that lines?

And yes, I've no clue what the problem is and am purely guessing.
I do not have access to Windows machine, XP or newer, or any version of IE.. so I'm working blind here :)

I've tried to talk to the Windows guys I know, but they've got no clue either and are having issues getting Windows XP and IE8 to reproduce the issue :(
 [2014-01-15 02:45 UTC] TygerGilbert at USAWebAdv dot com
I understand, Bjori. And I appreciate your efforts to solve this. I uploaded the screenshot to at your suggestion. It appears at:

At least I am not the only one who has seen this, so we know it exists, even if others are having trouble replicating it.
 [2014-01-15 05:49 UTC]
Looks like cmbecker69 at gmx dot de analyzes was dead on, its just missing the @media queries for > 670px (and other minor irrelevant pixel-perfect issues)

If someone knows of IE8 @media workarounds, that would be awesome
 [2014-01-16 16:02 UTC]
Perhaps I'm just incredibly biased, but I see no reason to fix the CSS 'problems'. The script issue is certainly valid as it absolutely prevents you from using the site. However, a sub-optimal browsing experience is exactly what you are asking for by using IE 8 anyway.

I see no reason to spend time working on this. If someone else does feel like spending time on it, that's okay. When doing so, please preserve and even enhance the mobile first design as it actually made things much easier than the desktop first design I previously attempted.
 [2015-01-03 11:12 UTC]
-Assigned To: googleguy +Assigned To: jacob
 [2015-01-11 08:53 UTC]
-Status: Re-Opened +Status: Closed
 [2015-01-11 08:53 UTC]'s support for browsers only covers current stable and prior release and this issue is related to an unsupported OS/Browser combination I am closing this one off.

Should someone want to support this, feel free to reopen and assign.
 [2015-01-11 08:57 UTC]
-Assigned To: jacob +Assigned To: Unassigned
 [2015-08-08 17:40 UTC]
Automatic comment on behalf of googleguy
Log: Patching typeahead.js to fix bug #66371
 [2015-08-09 00:06 UTC]
Automatic comment on behalf of googleguy
Log: Patching typeahead.js to fix bug #66371
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 05 05:01:29 2024 UTC