I experience the same problem. However, it depends on which site I'm being routed to. For example, page http://nl1.php.net/strtotime gives the mentioned popup. Page http://nl3.php.net/strtotime does not. I hope this helps troubleshooting this problem.

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 http://www.php.net.

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)

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: http://www.php.net/manual/en/function.addslashes.php 

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

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?

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 http://www.php.net/manual/en/ref.strings.php again (14:30 MST) and it still produces the error box.

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 :(

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
php.net.  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).

Someone mentioned typeahead.js being a problem somewhere else too..
Maybe that plugin just doesn't like IE8? Adam.. Could you check it out?

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 PHP.net site are developers, but if anything, I think that would make it even more important that PHP.net 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.

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 https://github.com/twitter/typeahead.js/pull/457/files which details the issue found in PR 457 here https://github.com/twitter/typeahead.js/pull/457

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.

Patch it please.

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!

Uh, I'm still getting the error.

You likely will need to clear your browser cache for changes to take effect.

I cleared the cache, closed the browser, reopened the browser and went to the PHP.net 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.

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.

I can confirm Tyger's latest report.  I have cleared the browser cache,
disabled caching altogether and get the updated typeahead.min.js, starting
with 
  (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).

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

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.

Could you upload the screenshot to http://imagebin.org 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 :(

I understand, Bjori. And I appreciate your efforts to solve this. I uploaded the screenshot to ImageBin.org at your suggestion. It appears at:
http://imagebin.org/286804

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.

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

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.

PHP.net'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.