Cuireadh an snáithe seo sa chartlann. Cuir ceist nua má tá cabhair uait.
I can no longer edit my custom content management system using Firefox
So far, the only way we've been able to allow people to edit their sites is by forcing them to use IE9 in compatibility mode. All other browsers fail for various reasons. Firefox is our workhorse browser, but we're desperate to have Firefox back.
I understand we also have some problems with our Remedy application -- not sure what's happening, but it's also no longer functional in Firefox. I'm wondering if there is a patch in the works that will address these issues?
BTW, it sounds a lot like this issue here: http://support.mozilla.org/en-US/questions/930042
All Replies (14)
Did it work in Firefox 13.0, or did you upgrade directly from a different version?
Have you had any problems with Flash? If you upgraded to Flash 11.3 at the same time, we probably should rule that out as an issue. Flash 11.3 doesn't load video in Firefox.
I think we need some "hands on" time with the applications to see whether, for example, they generate errors or warnings in Firefox's error console (Ctrl+Shift+j) that help point toward a solution or workaround.
I'm trying to find out if our Security office will grant you access to our dev environment. Meanwhile, my Firebug add-on has mysteriously disappeared, which is what I typically use to view errors / warnings. I'll see if I can get you any more information and access to our applications.
Interesting... I get an error when I log into the CMS. It says: $ not defined. Source code for the page is here: http://pastie.org/4126414.
$ apparently has something to do with the lightbox popups. Here are all of the messages / warnings I get (attached images), in case it helps.
I also tried to access the site via Seamonkey. Once again, the edit buttons were not visible to me on the page. I received most of the same errors, but found a few others that seemed interesting (attached).
Hi vedawms, I believe the only message which could break functionality is the one about missing support for the $, which in most cases indicates a problem loading the jquery library.
If everyone is having the same problem, I wonder whether it is related to the jquery library: how it's loaded or what vintage it is. Can you view the source of the page (Ctrl+u) and search for jquery and see whether it is loaded from the same server as your page or from a different server, and whether there is any difference in the protocol: http vs. https? If it's hosted locally, you may want to check the version number. If you click the url for src= in the source viewer, it should load the script file and the version number should appear near the top. It might need an update.
Actually, following the link in your pastie code, I see the answers:
It is loaded with the same protocol as your page and from your own server, but it is an older version (dating from 2009). I haven't researched whether there are any known incompatibilities with Firefox, but given the passage of just over three years, I wouldn't be surprised.
I think the applications are on different servers, so I don't think they share a JQuery library.
I'm wondering whether the error that says to look here: https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing is causing the JQuery to not load. I've logged into the site, but I'm not seeing it in the list of loaded scripts (see screenshot). I saw that there was a problem with the parsing in FF 11, so maybe the error has come back? (Reaching at straws here.)
FWIW, there are several very promising solutions here: http://stackoverflow.com/questions/879137/problem-with-jquery-in-internet-explorer-8. We're going to attempt an upgrade to a newer version of JQuery, and I'll report back if it solved the issue.
Upgrading to 1.7.2 version of JQuery did not solve the problem. Any additional thoughts?
Are you getting the same error that $ is not defined? Could you try the following edit.
Delete this existing code which appears mid-document in fragment18 in the body section:
And instead place this code at the end of the body:
This might reveal the search form before the document is fully loaded, but I'm not sure there is any harm in that.
In fact, why not just skip the steps of hiding and showing it? To avoid the need for the script, try removing this style block from the corresponding fragment18 in the head section:
To see if the $ error was universal across all of our sites, I logged into four or five other UCM sites. None of them threw the $ error, only the Art site. What's interesting is that for all sites, you can see editable areas if you look for them (e.g. mouse randomly around the areas where there used to be buttons to click on), but the icons continue to not show up.
The warnings coming from the console seem fairly benign, and it's only the Art site that throws a definite error. The only thing that seems consistent across all sites is the warning: "server does not support RFC 5746, see CVE-2009-3555".
Any other thoughts? I'm not sure a guest logon would help, but I can certainly pursue that line of action if you'd like to dig a little deeper.
Thanks in advance,