Hello,

we're using Liferay from quite a long time now and recently we have an unusual problem in one of our Liferay's websites, more specifically in the page settings section.

In our environment production, subpages don't load once you click the small arrow. This can only be reproduced on IE7 and IE8. Firefox, Safari and Chrome are working like a charm.
On IE, the "loadingAnimation.gif" comes next to the page title as to indicate the subpages are loading but the fact is that they unfortunately never load. I should add, this is the first time it ever happens on this website and that no delivery has been made for several weeks now, so probably this is either a problem of contribution or a problem from Liferay's Core.

After some hours of IE8 debugging it seems this is due to the (JQuery) AJAX call in the tree.js file (located in the /html/js/liferay/ directory) which is called on every subpages that should be loaded once you click the arrow.

toggle: function(obj) {
(...)
jQuery.get(
url,
function(html) {
subBranch.html(html);
branchInteraction();
pageImg.attr('src', pageImgSrc);
sessionClick();
}
)
}

Indeed, I noticed that (only with IE) the success function defined there is never reached. As this JQuery function doesn't let you know any further information about the possible reasons of the crash, I changed the call to :
jQuery.ajax({
type: "GET",
cache: false,
url: url,
success: function(html) {
subBranch.html(html);
branchInteraction();
pageImg.attr('src', pageImgSrc);
sessionClick();
},
error: function(request, status, error){
alert(request.status)
}
});

As a result, I'm now getting an alert pop-up with "122" in it, which represents the HTML response of the AJAX call. After some researches, it seems this kind of error is due to a "too long" URL passed to the Ajax function.
In our case that could possibly be the problem since the url is made of more than 2500 characters. We noticed the longest part of the URL was the "_88_openNodes" parameter, which is made of 1740 characters. Moreover, of our 6 Liferay websites, this one has the highest number of pages, so everything tended to prove it was the cause of the problem.

To be sure of this, we tried to dump the production database and copy it into our developpement database but mysteriously there is no way we can reproduce the problem : subpages load correctly even with extra-long URLs, so we're guessing the problem might be somewhere else.

We also tried to change the Ajax request type from "GET" to "POST" (as written on forums dealing with the '122' Ajax request status), but the AJAX call keeps crashing on IE.

Has anyone ever experienced the same problem, and eventually found a solution ? Could that be possibly some kind of Liferay's Core bug ?

Thanks in advance

Hi Olivier,

What environment (OS, bundle version and type) are you running on? It will greatly help us to debug this -- it does seem pretty serious and we'd like to figure out how to reproduce this bug. Thanks for finding this!

Warm regards,
Sam

Hi Samuel, thanks for your fast answer.

Sorry for not mentionning these informations in my first post. We're using Liferay Portal Standard Edition 5.2.2 (build 5202) on an Red Hat Enterprise Linux OS (ES release 4).

Regards,

Hi Olivier,

It's going to take some time but I'll try to reproduce your problem asap. It's possible that this is already a LP 5.2.2 bug -- I will search but you can also look at the Liferay JIRA to see if this is a known issue. I know that this is not a problem in Liferay 5.2.3, so you may benefit from an upgrade. Otherwise, there's likely a patch available on the Liferay JIRA.

I'll let you know how my reproducing attempt goes. Any details you have on how to reproduce this problem would be greatly appreciated

Warm regards,
Sam

Hi Samuel,

I already had a look on the Liferay JIRA bugtracker but I couldn't find any known issue that could possibly looks like our problem there.
About the way to reproduce the bug, first of all the issue is only concerning Internet Explorer 7/8 (all other browsers work perfectly but our client mostly uses IE).

Here are four screenshots to help you reproducing the bug :
- Screenshot-1-Page-Settings-Webpage > the 'Page Settings' webpage (I hope you are a bit familiar with french translations ;)),
- Screenshot-2-Endless-loading > the result after clicking the subpages arrows under IE7/8, where subpages seem to be loading endlessly,
- Screenshot-3-Firefox > the result of the same manipulation using Firefox this time, where subpages are loaded correctly,
- Screenshot-4-IE8-Debugger > finally, I hope the last one can bring some more usefull informations to you : it is a screenshot of the IE8 debugger when clicking these arrows. I just added 3 breakpoints, the first one which is the line adding the "loadingAnimation.gif", the second one in the success function and the last one in the error function. As planned, on IE7/8 the error function is always reached and we can also see on the right part of the debugger the request attributes indicating the "122" error status.
Last thing, as I indicated previously, the URL given to the AJAX function is super-huge, I don't know if that's a normal behaviour or not, it's made of almost 2700 characters.

I hope these informations can be any relevant for you, tell me if you need any other information that could help you reproducing/solving the issue.
Anywaus thanks a lot for your efforts.
Olivier

Hi Olivier,

This has been more than helpful. I will work on reproducing it asap.

Thanks!
Sam

Hi Olivier,

Just wondering, are you able to reproduce this on 5.2.3? If it is no longer an issue on 5.2.3, you should probably just upgrade to resolve the issue. We can't fix bugs on older versions like 5.2.2 if they're fixed on 5.2.3 -- the fix is to upgrade in that case.

At any rate, if it is a bug on 5.2.3, then we need to do a fix. I will continue to investigate the issue and get back to you on this. Also -- the images you posted seem to have gone. Can you repost them if you get a chance?

Thanks for your help!

Warm regards,
Sam

Hi Samuel,
We haven't tried to upgrade to 5.2.3 yet since we were hoping you would know what's going on with the subpages loading problem ;) Anyways, as you told us, I warned our client that it might be useful to upgrade the server, at this moment I don't know whether we'll have to make it or not. He'll probably wait until we find some evidences it's indeed a Liferay's bug and that the next version can fix it to move on. Still if I get some time I might try on my own and see if the problem can be reproduced on 5.2.3, I'll let you know asap.

Moreover, here are the four screenshots re-uploaded on some other ftp, I hope you can get them all this time :
http://dl.free.fr/eW0HLpQGa/SS-Liferay-IE7-IE8-Subpages-1.png
http://dl.free.fr/pyso6t4od/SS-Liferay-IE7-IE8-Subpages-2.png
http://dl.free.fr/otKXvHewG/SS-Liferay-IE7-IE8-Subpages-3.png
http://dl.free.fr/lhtHOvgVA/SS-Liferay-IE7-IE8-Subpages-4.png

Thanks a lot sir,
Olivier

Hi Olivier,

I'm downloading the 5.2.2 bundle as we speak. I'll try to reproduce -- reporting back with the results asap!

Warm regards,
Sam

Hi Olivier,

IE8 seems to work fine for me: see screenshot. Now testing IE7. I'll keep you posted!

Warm regards,
Sam

Anexos:

ie8-test.bmp (1.990,6k)

Hi Olivier,

I went and booted up a VM with IE7 and turns out it works there too.

Maybe there's something wrong with your internal javascript or something...? If there's any way I can be of any more help please let me know

Thanks
Sam

Actually, the only reason why I changed that part of code is because the original code doesn't let you know why the AJAX call fail since you can't define any error callback function using JQuery.get(), but of course the bug was detected before I turned it into the JQuery.ajax() function.

Like I said, here is what noticed :
- I'm having a 122 status error, which seems to indicate the URL is too long to be handled by the browser (http://www.vicconsult.com/tips/http-error-codes.html), and indeed, looking at the URL given in the ajax request, I noticed that URLs were made of around 2700 characters while IE supports no more than ~2000. This would also explain why the bug would be specific to IE and why it can't be reproduced on other browsers.
- Also, I wondered how come the URL was that long. Then I took a big breath and looked into it : I noticed there is a special parameter called _88_openNodes which value is made of 1740 characters. Even if I'm not sure of what I'll say I clearly suspect this parameter to have a link with the number of pages/subpages composing the website. I bet that the more you have pages in your site the bigger is this parameter, which would also explain why the "page settings" page had been working for ages and suddenly crashed using IE, without having any deliver made recently on our production environment.
- Finally, the website where that bug was found has many articles in it, each article being linked to a specific page (this way we can have friendly-urls for each article), which means there are almost has many pages than articles in the site. After checking the database, there are 108 pages stored in the 'Layout' table, so 108 pages in the "Page Settings" section.

All these observations make me think the bug has a link with the number of pages composing the website. The only problem with my explanation is that it shall be solved using POST instead of GET in the ajax call, but for some reasons the problem keeps appearing even if I make the change.

That being said, maybe you could try to reproduce the bug on a larger site because it seems yours seem to be much smaller at the moment ?
Thanks a lot for you help
Olivier

Wow thanks Olivier,

This does seem pretty serious! I need to test two large-scale bugs today then -- this and another where large number of files in document library might cause an error.

Thanks for the detail, I'll get to work asap. I'll let you know how this goes!

Just a note though -- I'll be testing in 6.0.x. If this is not reproducible in 6.0.x, then your solution is likely just to upgrade. I looked through the JIRA for a ticket like this but there doesn't seem to be one...there's a pretty high possibility that this is a new bug.

I didn't realize this until today but technically 5.2.x has reached end of product life, so unless you are EE, there are no more fix versions coming out other than the 6.0.x series. You can get backported patches but you have to find them in the JIRA.

At any rate, I'll keep you posted.

Warm regards,
Sam

Hi Samuel,

OK thanks for the tip, we might just upgrade Liferay and see if that somehow solve the problem. Tell me if you can reproduce the problem on Liferay 6.0.x though!

Warm regards,
Olivier

Hi Olivier,

I was unable to reproduce the problem in 6.0.x. I think your issue will be resolved by upgrading.

If I can help in any other way please let me know!

Warm regards,
Sam

Hello Samuel,

I'am in charge of the Liferay powered website after Olivier left for another project.

Regarding the issue on IE 7/8 when trying to unfold subpages, I found the corresponding issue on JIRA : http://issues.liferay.com/browse/LPS-8605.

After reading it I decided to upgrade Liferay to version 5.2.3, it solved the problem in our development and testing environnements (I was very happy ), but unfortunatly, after upgrading our production environnement, the issue is still here on IE 7 and 8 ...

The only explanation I could think of is the size of the website in the production environnement which has more pages than our testing environnement. That's the only notable difference between our testing environnment (which works fine) and our production environnement.

If possible, could you try to reproduce the bug in a large website running Liferay 5.2.3 ?

Any help or hints to solve this problem would be highly appreciated.

Thanks in advance,

Kind Regards,

Joaquim

Hello,

Can anyone help me or give me some hints to solve this problem ? (see my post above)

I really need to solve this, any kind of help would be highly appreciated.

Thanks in advance.

Joaquim

Hi,

need help too !

I'm on LP6.0.6, and the manage pages page hang on IE8. It seems to be correlated with a (not so) hign number of pages in the layout.

Said apart, I find the way this treeview is implemented a little bad. Everay action on the manage page launch a refresh of the tree with many json exchanges. Couldn't it be a little simpler ? Why such a complicated way to display a tree of the pages ?

if you look at other part of LP (site Map, selector for "copy parent" page), it's easier and faster !

Regards