Closed Bug 640499 Opened 15 years ago Closed 15 years ago

CA Servicedesk is unusable in Firefox 4 since beta10

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 627361

People

(Reporter: jellegie, Unassigned)

References

Details

(Keywords: regression)

Attachments

(5 files)

Shows the javascript console of firebug when clicking context menu items of tickets in CA Servicedesk
185.27 KB, image/png
Details
CA Servicedesk errors while in Firefox 4 safe mode.
155.89 KB, image/png
Details
All messages when loading service desk page + error when clicking ticket id.
357.64 KB, image/png
Details
Build config of the first broken nightly build.
32.56 KB, image/png
Details
No Base Tags in Frame in question
110.42 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Our company uses the CA Servicedesk tool as helpdesk system which makes heavy use of JavaScript and JavaScript Popup Windows for Ticket Details Windows. These do not open anymore since FF4b10 (tested on Vista64 (with 32bit FF) and Ubuntu Linux 10.10 32bit. Reproducible: Always Steps to Reproduce: 1. Connect to the servicedesk system 2. Try to view ticket - a window with the ticket details should pop up 3. Actual Results: Nothing happens Expected Results: Window with ticket details pops up. Unfortunately I do not know of any public servicedesk installation so I cannot give you a pointer to such a site.
Reporter, please try to provide a public testcase. Or, could you please poke around the servicedesk code, to give us an idea of what happens there and what is not working properly. Thanks.
Alex, for the moment I am not able to dig deeper into this as I have to do some normal business. I'll come back to this later providing more info. Just as a summary: - it appears that FF is not able to find some Javascript routines though it should be available to the browser - the .js containing the function(s) in question is loaded CA Servicedesk version is r12_1CP-196 . I've found more reports similar to mine but not as bug report: http://www.google.de/search?sourceid=chrome&ie=UTF-8&q=firefox+4+ca+servicedesk http://support.mozilla.com/de/questions/791611 I'll dig further into the JS code but would also recommend to contact CA on this? They might be interested to have their tool working in FF4 as it used to work in FF3.x, IE and Opera... Thanks
Alex, I'm trying to get a contact @CA for them to touch base with you. As said - I cannot get you a URL to use to test as this is an internal system within our company but CA perhaps can provide some site to test against? Regards Jens
Could you see if there are any errors in the console (just errors, don't need to warnings) and paste them here please. Use Ctrl + Shift + J to access. Also, could you see if the issue occurs if using Firefox in safe mode: http://support.mozilla.com/kb/Safe+Mode How about with a new, empty testing profile? (Don't install any addons into it) http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile
Keywords: regression
Version: unspecified → Trunk
will also test safe-mode and an empty profile...
CA Servicedesk errors while in Firefox 4 safe mode.
I've talked to my manager to also get in touch with CA and open a ticket there - perhaps they can help you out with a demo or public site of the system ...
Also tested a clean profile - no difference ...
This is likely going to be something that CA has to fix, but the fastest way of tracking this down for now is probably to find the regression range using this bisecting tool: http://harthur.github.com/mozregression/ It will take ~30 mins from start to finish, but should narrow down the range to a 24 hour period of changesets, which will make it much easier to guide CA/confirm for sure that Firefox is behaving as expected. I'd do it myself, but obviously don't have access to a CA servicedesk install.
Meant to add: It's likely you may not have the time to do the above (given you are at work), but just thought I'd mention it in case.
We have CA Service Desk 12.1 and this has been a problem in both the RC and the final. Unfortunately, we'll be stuck on Firefox 3.6.x, IE on a PC, or see if another Mac browser will work with CA. Error: do_default is not defined Source File: javascript:do_default(1) Line: 1 Firefox Version 4.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0
Out of interest, could someone see if CA Service Desk works with Chrome 11 dev: http://www.google.com/chrome/eula.html?extra=devchannel (Chrome 10/11 has also made html5 parser and strict mode javascript changes, like Firefox 4, so if it doesn't work either, means it's even more likely a problem that CA need to fix)
Both Chromium 12.0.700.0 and Chrome 11.0.696.16 dev do not have this very same issue (though they have a different issue with the menu bar not loading). Detail view and edit windows for tickets do open as expected. Will check with the regression tool later ...
Hi, is it possible that mozregression cannot be used behind an authenticating proxy? I've set both http_proxy and ftp_proxy (export http_proxy="http://username:password@proxyhost:port/" && export ftp_proxy=$http_proxy) and it's complaining that it's not able to find the server. If I put ftp.mozilla.org's IP in /etc/hosts and /c/Windows/system32/drivers/etc/hosts httplib.py complains that it's got an AttributeError: $ mozregression --good=2011-01-11 --bad=2011-01-21 Traceback (most recent call last): File "c:\mozilla-build\python\Scripts\mozregression-script.py", line 8, in <mo dule> load_entry_point('mozregression==0.2', 'console_scripts', 'mozregression')() File "build\bdist.win32\egg\mozregression\regression.py", line 125, in cli File "build\bdist.win32\egg\mozregression\regression.py", line 60, in bisect File "build\bdist.win32\egg\mozregression\runnightly.py", line 199, in start File "build\bdist.win32\egg\mozregression\runnightly.py", line 84, in download File "build\bdist.win32\egg\mozregression\runnightly.py", line 103, in getBuil dUrl File "build\bdist.win32\egg\mozregression\runnightly.py", line 118, in getUrl File "build\bdist.win32\egg\httplib2\__init__.py", line 1129, in request File "build\bdist.win32\egg\httplib2\__init__.py", line 901, in _request File "build\bdist.win32\egg\httplib2\__init__.py", line 871, in _conn_request File "c:\mozilla-build\python\lib\httplib.py", line 984, in getresponse method=self._method) File "c:\mozilla-build\python\lib\httplib.py", line 330, in __init__ self.fp = sock.makefile('rb', 0) AttributeError: 'NoneType' object has no attribute 'makefile' Any comments/ideas? Thanks ...
I'm not sure what's happening there. I didn't make the tool, but have filed a bug with it's author here: https://github.com/harthur/mozregression/issues/7 In the meantime (if anyone in this bug can spare the time obviously), the range could always be found by manually downloading the non-installer versions of the nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/ and bisecting the range manually. You will want to use the mozilla-central variants & note that the format is YYYY-MM-DD-HH; whereby HH varies depending on what time that platform was built. Once you have found the 24 hours period please post the revision ID of bad vs good, since the date itself isn't very precise (see about:buildconfig to find the rev ID it was built from).
That's what I was trying now - the hint with the buildid in about:buildconfig is very helpful...
Here we are - this is the buildconfig of the first version where the menu is broken: about:buildconfig Source Built from http://hg.mozilla.org/mozilla-central/rev/3d4620449437 Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 14.00.50727.762 -TC -nologo -W3 -Gy -Fdgenerated.pdb -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 d;D:\mozilla-build\msys\mozilla-build\python25\python2.5.exe -O e;D:\mozilla-build\msys\builds\moz2_slave\cen-w32-ntly\build\build\cl.py cl 14.00.50727.762 -GR- -TP -nologo -Zc:wchar_t- -W3 -Gy -Fdgenerated.pdb -wd4800 -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 Configure arguments --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --enable-tests
Sorry to be a pain, but do you have the build ID from the one before (so I can get a pushlog of all changes within that timeframe)? Thanks!
Ed, you're not a pain at all since you're trying to help me (and others) solving a problem we have with "your baby" ;-) I thought that 3d4620449437 was the build id? I had copied all of the info contained in about:buildconfig into my previous comment. The package used was http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/01/2011-01-15-03-mozilla-central/firefox-4.0b10pre.en-US.win32.zip Thanks.
Sorry for not being clear, that was the correct ID, but I also needed the ID of the day before, in order to work out the range. However, using the info in comment 19 and comment 21 I've managed to manually look it up myself (presuming that 2011-01-14-03 win32 opt was the last one that worked), so have everything needed now - thanks. This gives: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f412256da4&tochange=3d4620449437 Unfortunately there are a lot of changes in that range, including a big merge from the javascript project repository tracemonkey. Please could you try the tracemonkey nightlies (same ftp location as before, but use the -tracemonkey variants rather than -mozilla-central) to see if we can get a smaller range and then compare with the mozilla-central changes. The date range will be slightly different - at first guess I'd start by bisecting tracemonkey in the range ~2011-01-06 to ~2011-01-14 and see how you go from there. As before please can I have the rev IDs of both the last good and also the first bad - thanks! (In reply to comment #21) > Ed, you're not a pain at all since you're trying to help me (and others) > solving a problem we have with "your baby" ;-) I don't work for Mozilla, just helping out; a la http://www.mozilla.org/contribute/areas.html :-)
Also, marking new given the confirmations. Provisionally moving to Core::JS given comment 2, the TM regression range will hopefully confirm either way.
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
Keywords: regressionwindow-wanted
Product: Firefox → Core
QA Contact: general → general
Yes - you're right with the assumption that the one from 01-14-03 was working ... Since you're somehow helping out it's become (at least partly :-) also your baby, isn't it? Will check with the tracemonkey builds - might take until tonight CET 'coz I don't have that much time left this afternoon though.
Ok - already found it: b034f8e72b2f which is the -tracemonkey from 2011-01-15-03 is broken, the previous a5d0ccdb9985 from -tracemonkey 2011-01-14-03 works.
That corresponds to http://hg.mozilla.org/tracemonkey/pushloghtml?tochange=b034f8e72b2f&fromchange=a5d0ccdb9985 Looking at the intersection of the ranges, on the two trees, I think we end up with http://hg.mozilla.org/tracemonkey/pushloghtml?tochange=b034f8e72b2f&fromchange=e8c8df3f17f2 Is the code in question in a frame? If not, what does "javascript:alert(document.baseURI)" say in the working and non-working builds (most importantly, is it identical)? If it's in a frame, can you look for base tags in that frame?
I was not able to find any base tags in the source of the frame - I'm not able to use mozilla's built-in "view frame source" cmd as the normal right-click menu has been disabled by CA and I'm not able to find it anywhere in the menu (not even in the classic menu enabled by pressing "Alt").
OK. If I created some test build for you from the regression range, would you be willing to try those? That way we could narrow things down to the exact checkin that caused the problem... I know it's a pain, but without access to the site itself we sort of have limited options here. :( If you're willing to do the test build thing, which OS can you run builds on? I assume Windows is simplest?
Ed, i'll test happily - win32 win64 linux32 solaris10 hp-ux - choose please :)
Linux32 it is. I'll get some builds started.
Hi Boris, (sorry I previously hadn't noticed that it wasn't Ed who offered to build the test versions since I was reading the message on my cell phone ...), I tested with the version you built and it doesn't work - so that's too new ...
Good. That's before the TM merge. I'll spin up the next test build. ;) Range is now: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f412256da4&tochange=6419e802aab0
This version works!
New range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3ba98d905bdf&tochange=6419e802aab0 Which is odd, because nothing in there looks all that plausible to me. Could you please double-check the build from comment 34, just in case? In any case, I've pushed another tryserver run.
b306ff2ce5f4 works as well and I've also verified that 49b4ca992c96 works.
New range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd51bbe88214&tochange=6419e802aab0 I'm starting to wonder about that XHR change. I pushed another build to try...
Boris, just sent you an email ...
Jens walked me through reproducing this, and we applied the DOM Inspector hammer. The problem is that the relevant frame had this somewhere way deep inside the page: <base target="_top"> So the regression is from bug 619220; the followup that made @target do the right thing is in our remaining regression range, of course. Jens, what happened here is that we changed how we handle <base> tags. In Firefox 3.6 a <base> outside <head> only applies to links that come after it in the DOM and are generated by the parser (the parser flags links with the "current base URI" and such). In Firefox 4, the first <base> in the DOM applies to all links. I'm assuming that the page has something like this: <a href="javascript:doSomeStuff()"> somewhere before the <base> tag, or generated via DOM calls. In Firefox 3.6 that would run the function doSomeStuff in the document the <a> is in. In Firefox 4 it runs the function doSomeStuff in the topmost frameset document, where it doesn't exist, of course. See bug 619220 for links to the various discussion about how <base> should behave, but the short story is that the Firefox 3.6 behavior is nuts and we don't really want to restore it. At the same time, the Chrome behavior (which makes this particular page work, because they only allow <base> in <head>) breaks sites per bug 619220 and I've lost track of what IE does: it's not consistent between versions. And I just realized that we even sort of knew about this issue with another CA product: see bug 627361. Or is this the same product?
Assignee: general → nobody
Blocks: 619220
Component: JavaScript Engine → DOM
Keywords: regressionwindow-wanted
QA Contact: general → general
Per bug 627361 comment 50, sounds like this is the same product. Jens, thank you for all your time. I'm sorry I didn't catch on to the CA thing sooner. :(
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: