Open Bug 627361 Opened 14 years ago Updated 2 years ago

CA Unicenter needs Gecko not to honor the first <base target> in the document

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: desidero, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

Frame part of testcase
(deleted), text/html
Details
Single frameset page that uses the attachmentlink to bugzilla for the frame.
(deleted), text/html
Details 
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

Ever since the January 17th nightly build of Minefield came out, the do_default(#) functionality on an internal website is broken. It's part of a major CA product (Unicenter), so I'd imagine that it's something that would be noticed elsewhere as well.

I can get into Unicenter and almost everything works fine, but when I click on tickets to view them, nothing happens.

I used the console in Firebug to see what's going on. Here's the error: do_default is not defined
javascript:do_default(0)
Line 1

I've looked around for other posts or discussions about this, and I can't see any reason why the code won't work. It was fine in the older versions of Firefox as well as all the other browsers (IE, Chrome, Opera).

Reproducible: Always

Steps to Reproduce:
1. Click link
2. Nothing happens
Actual Results:  
Nothing. Errors had to be investigated in Firebug.

Expected Results:  
A window should have popped open with information on the ticket.
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Reporter, we really need more to go on here... What does the script look like?  What does the HTML look like?  I understand that the site is internal, so you can't give us a link to it, but we need to know _something_ about the site.
Unicenter is a java-based web application. I don't know if they'd be okay with people posting all of the javascript from the page, so unfortunately I can't do that. 

Here is the HTML for the link being clicked:
<a id="rslnk_0_0" class="record" href="javascript:do_default(0)" onblur="blurRow(0)" onfocus="selectRow(0)" tabindex="110" title="Request # 1261192">1261192</a>

There are a ton of scripts embedded all over the page, so I'm not entirely sure what it's activating. I tried checking it out in an older version of FF where it still works properly, but I don't know how to trace the javascript calls. I have no idea how to tell which default action it's taking. Do you have any advice?
Can you find where the scripts involved define the do_default function?

And just to confirm, can you try doing this in the url bar:

  javascript:alert(do_default)

that should alert a function's source in 3.6 and presumably alerts undefined in 4.0, right?
Entering that in the url bar didn't cause anything to happen in FF3.6 or 4b10

However, I have good news! I figured out how to trace what I did to some extent and found the do_default(n) function. Here it is:

function do_default(n)
{
var persid=rs.records[n].persid;
var midPos=persid.indexOf(":");
var sObj="";
if(midPos>=0)
{
sObj=persid.substring(0,midPos);
}
if(typeof lastActiveMenu=="object")
{
hideContextMenu(0);
if(typeof lastActiveMenu.ifired=="boolean"&&lastActiveMenu.ifired)
return;
}
if(typeof __list_edit=="object"&&
__list_edit!=null&&
__list_edit.isVisible)
{
if(!ignoreClick)
focusEditForm();
ignoreClick=false;
}
else
{
if(rs.backfillReq)
rsBackfill();
else if(rs.isProfileBrowser&&typeof(linkOnclick)=="undefined"){
profile_browser(persid);
window.parent.close();
}
else if(rs.createAlg)
{
rsShowDetailNoPopup(persid);
}
else if(typeof(linkOnclick)=="function")
{
(linkOnclick)();
return;
}
else if(typeof cfgShowDocumentEditor!="undefined"&&cfgShowDocumentEditor)
{
var vDocID=persid.split(":");
var doc_id=vDocID[1];
OpenDocumentEditor(doc_id);
return;
}
else if(typeof cfgShowDocumentViewer!="undefined"&&cfgShowDocumentViewer)
{
var vDocID=persid.split(":");
var doc_id=vDocID[1];
var iDocViewMode=GetDocViewMode();
if(iDocViewMode==0)
OpenDocumentViewer(doc_id,1);
else
OpenDocumentViewer(doc_id,2);
return;
}
else if(sObj=="INDEX_DOC_LINKS")
{
var sCatID=rs.records[n].relAttr;
if(sCatID.indexOf(":")!=-1)
{
var features="directories=no"+
",location=no"+
",height=665"+
",width=895"+
",status=no";
popup_window('','SHOW_DETAIL',0,0,features,'PERSID='+sCatID);
}
else
{
var features="directories=no"+
",location=no"+
",height=450"+
",width=600"+
",status=no";
popup_window('','SHOW_DETAIL',0,0,features,'PERSID=KCAT:'+sCatID);
}
return;
}
else if(sObj=="CI_DOC_LINKS")
{
var sKDID=rs.records[n].relAttr;
var features="directories=no"+
",location=no"+
",height=665"+
",width=895"+
",status=no";
popup_window('','SHOW_DETAIL',0,0,features,'PERSID=KD:'+sKDID);
return;
}
else if(sObj=="NOTIFICATION")
{
var sNotifyee=rs.records[n].relAttr;
if(sNotifyee.match(/[\.\@]/))
{
window.open("mailto:"+sNotifyee);
return;
}
else
{
persid="cnt:"+sNotifyee;
rsShowDetailPopup(persid);
return;
}
}
else
{
rsShowDetailPopup(persid);
}
}
}

I ran the Profiler in Firebug to find out where it came from. It knows that it is in std_list.js in FF3.6, but it's undefined in 4b10.
I forgot to mention: when I ran the Profiler, it called 5 other functions from std_list.js, so it is loading the javascript file.
Hmm.  Would you be willing to mail std_list.js to me (on the assumption that you don't want to attach it to this public bug)?
Sure. Send it to your mit email address?
Yes, please.
Thanks for the file!

Unfortunately, the obvious things I tried with that file lead to do_default being defined in the window scope, as it should be.

A few more things to try:

1)  If you go to about:config and change the "html5.enable" preference to 
    false, does the behavior go back to what it was in 3.6?
2)  If it does not, would you be willing to try to narrow down when the problem
    first appeared using nightly builds?  I can give you some directions on
    doing that, if so.

I really appreciate your helping out here!
I tried disabling html5, but that didn't help it.

The problem started happening after the automatic nightly build update on January 17. It was fine before then. Let me know if there's any other information I can give you.
There is, actually.  Could you load about:buildconfig in the first broken build and the last working one, and post the http://hg.mozilla.org from both of those builds in this bug?
blocking2.0: --- → ?
Good call on that. It didn't break until the 17th for us, but it seems that wasn't the actual build date when it broke. I'm not sure why we didn't get the daily updates between then and the 17th, but in any event...

Last Working Version(1/14/11):
http://hg.mozilla.org/mozilla-central/rev/9f412256da4c

First Broken Version(1/15/11):
http://hg.mozilla.org/mozilla-central/rev/3d4620449437

Looks like you were involved with that change, so it should be easier to debug, I hope!
OK, so this range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f412256da4c&tochange=3d4620449437

Hmm.  Does the document that has the <a> tag from comment 2 have any <base> tags?
Nope, I can't find any <base> tags anywhere in the entire document. Here is all of the HTML for the portion of the screen dedicated to the links I'm trying to follow:

<div id="idResults" style="z-index: 0;">
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<table width="100%" cellspacing="0" cellpadding="0" border="0">
<div id="scrollbarDiv2" class="ScrollAuto" style="height: 455px;">
<form action="/CAisd/pdmweb.exe" method="POST" name="frmList">
<input type="hidden" value="(group.group_list.member IN (U'270D543643151D4EAB11AD2DDCE162FC')) AND (assignee IS NULL) AND type = 'R' AND active = 1" name="KEEP.save_where_clause">
<table id="rsTbl" class="table" width="100%" cellspacing="1" cellpadding="0" border="0" summary="Request List Search Results ordered by Open Date">
<tbody>
<tr>
<tr id="rsmsg0">
<tr id="rsTR0_0" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "0",event)" onclick="rsRowClick(this,"onclick","0", event)">
<td id="rs_0_ref_num" class="results" valign="middle" align="left">
<a id="rslnk_0_0" class="record" href="javascript:do_default(0)" onblur="blurRow(0)" onfocus="selectRow(0)" tabindex="110" title="Request # 1262524">1262524</a>
</td>
<td id="rs_0_type" class="results" valign="middle" align="left">Request</td>
<td id="rs_0_status" class="results" valign="middle" align="left">Open</td>
<td id="rs_0_open_date" class="results" valign="middle" align="left">01/21/2011 11:40 am</td>
<td id="rs_0_priority" class="results" valign="middle" align="left">3-Medium</td>
<td id="rs_0_group" class="results" valign="middle" align="left">MSIT Tech Support</td>
<td id="rs_0_assignee" class="results" valign="middle" align="left">Assignee: </td>
</tr>
<tr id="rsTR0_1" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "0",event)" onclick="rsRowClick(this,"onclick","0", event)">
<tr id="rsmsg0">
<tr id="rsTR1_0" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "1",event)" onclick="rsRowClick(this,"onclick","1", event)">
<tr id="rsTR1_1" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "1",event)" onclick="rsRowClick(this,"onclick","1", event)">
<tr id="rsmsg1">
<tr id="rsTR2_0" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "2",event)" onclick="rsRowClick(this,"onclick","2", event)">
<tr id="rsTR2_1" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "2",event)" onclick="rsRowClick(this,"onclick","2", event)">
<tr id="rsmsg2">
<tr id="rsTR3_0" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "3",event)" onclick="rsRowClick(this,"onclick","3", event)">
<tr id="rsTR3_1" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "3",event)" onclick="rsRowClick(this,"onclick","3", event)">
<tr id="rsmsg3">
<tr id="rsTR4_0" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "4",event)" onclick="rsRowClick(this,"onclick","4", event)">
<tr id="rsTR4_1" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "4",event)" onclick="rsRowClick(this,"onclick","4", event)">
<tr id="rsmsg4">
<tr id="rsTR5_0" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "5",event)" onclick="rsRowClick(this,"onclick","5", event)">
<tr id="rsTR5_1" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "5",event)" onclick="rsRowClick(this,"onclick","5", event)">
<tr id="rsmsg5">
<tr id="rsTR6_0" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "6",event)" onclick="rsRowClick(this,"onclick","6", event)">
<tr id="rsTR6_1" class="results0" oncontextmenu="rsRowClick(this,"oncontextmenu", "6",event)" onclick="rsRowClick(this,"onclick","6", event)">
<tr id="rsmsg6">
<tr id="rsTR7_0" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "7",event)" onclick="rsRowClick(this,"onclick","7", event)">
<tr id="rsTR7_1" class="results1" oncontextmenu="rsRowClick(this,"oncontextmenu", "7",event)" onclick="rsRowClick(this,"onclick","7", event)">
<tr id="rsmsg7">
</tbody>
</table>
<table width="100%" cellspacing="0" cellpadding="0" border="0">
</form>
</div>
OK, could you try the build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/bzbarsky@mozilla.com-54eae0f15976/try-w32/ ?

That's from partway through the regression range.  It also has a modification to log the link's target to the console ("Error Console" under the tools menu) whenever a link is clicked.  The two question are whether it shows the bug, and if so what it logs when the link in question is clicked.
This is what shows up in the console when I do that. The "Target is: _top" messages are warnings and the do_default message is an error.

1. Target is: _top
2. Target is: _top
3. Target is: _top
4. Target is: _top
5. Error: do_default is not defined
   Source File: javascript:do_default(0)
   Line: 1
6. Target is: _top
7. Target is: _top
8. Target is: _top
9. Target is: _top
10.Target is: _top
11.Target is: _top
12.Target is: _top
13.Target is: _top
OK.  Is the link in question in a subframe?

How did you get the source in comment 14, by the way?
Yes, the link is in a subframe. The HTML from comment 14 is from that subframe. There is a top portion, a navigation section on the bottom left, and a detailed information section on the bottom right. If it helps, I can send you a screenshot of the page.
> The HTML from comment 14 is from that subframe

And you got the text in comment 14 using the "This Frame > View Frame Source" option in the context menu for that subframe?  It's sort of weird that it has no <body> tag and the like...
It's set up so that the normal context menus don't show up when you right click on that site. It pops up with a custom menu for the web app.
You should be able to override that by toggling the preference "dom.event.contextmenu.enabled" to "false" in about:config.

If you didn't get that source via the context menu, how did you get it?
Looks like you were right. There is a <base> tag in that frame:
<BASE TARGET="_top">

I used Firebug to examine the HTML within that frame before.
Actually, after finding that, I did a bit more digging and it appears that it did show up in Firebug. I'm not sure how I missed it before. The base tag is pretty close to the end of the frame's HTML.
Ok, thanks!

So this is a regression from bug 619220, then, sounds like.

If you can get the actual source for the frame (not what Firebug reports; it reports a serialization of the DOM), that would be _really_ helpful.

Henri, it sounds like at least for Gecko this page may depend on the old behavior where different anchors had different base hrefs.  :(  Did other browsers have that behavior too?
Assignee: general → nobody
Blocks: 619220
Status: UNCONFIRMED → NEW
Component: JavaScript Engine → DOM: Core & HTML
Ever confirmed: true
Keywords: regression
QA Contact: general → general
Note that if I read comment 0 correctly, this is some enterprise web app that depends on the old behavior, and not a custom-built web app.  Which means that there are lots of places that will run into this problem, so it's not like we can get this one instance fixed.  :(
But reporter, I'd still like to see the original source; I really need to know whether that <base> tag is in the original source or is added dynamically...
(In reply to comment #24)
> Did other browsers have that behavior too?

Opera 11 seems to have it.

Chromium 8 and Safari 5 don't have it, but Safari honors the last <base target> in the doc while Chromium honors the first. I guess Chromium has a newer snapshot of WebKit.

IE6 had it, but it was dropped in IE7 (even from the quirks mode it appears!) so that IE7 and later have roughly the behavior that broke hyperlatex output instead.

(In reply to comment #25)
> Note that if I read comment 0 correctly, this is some enterprise web app that
> depends on the old behavior, and not a custom-built web app.  Which means that
> there are lots of places that will run into this problem, so it's not like we
> can get this one instance fixed.  :(

I think we shouldn't back out bug 619220, because for <base href> united.com is high-visibility and for <base target> we know that hyperlatex output is sprinkled around the Web. For this bug, we don't really have data about the impact and it would be unfortunate to re-break known stuff over concern about the unknown.
I just now realized that CA in comment 0 meant ca.com--not certificate authority. Please disregard what I said about unknown deployment scope.

Do we have a point of contact at CA Technologies?
Summary: Minefield javascript do_default isn't working properly → CA Unicenter needs Gecko not to honor the first <base target> in the document
> I think we shouldn't back out bug 619220

I think we shouldn't either; the question is whether we should reintroduce the insanity we used to have. :(
And are we sure that just not honoring the first <base target> would do the trick?  It sounds to me like there's only one <base target> here (though again, the actual source of the page would really help with determining that).  So as long as we honor <base target> outside <head> and apply it to links that are earlier than itself in the document, we'll have a problem with the Unicenter apps...
Do we know if Unicenter is in the quirks mode? (Yeah, I know that introducing new mode differences is a last-resort thing.)
I sent Boris an email with more information on the way the page is laid out as well as more HTML. While getting it all together, I noticed that the page does render in Quirks mode. The one meta tag is IE=EmulateIE7 if that matters.
Yeah, looks like the only <base> tag around is the <base target="_top"> that comes right before the footer setup script runs.

The page in question is in quirks mode.
The hyperlatex output is in the Almost Standards Mode, so making a quirk could make both work, but making new quirks is bad, of course.
Especially when the quirky behavior is sorta nuts.  :(
> Do we have a point of contact at CA Technologies?

Been a while so all our old CA contacts are probably dead.  bc or kev might have some ideas.
this might be another one where we want to spider to see how frequently the content pattern appears in the wild.
Wouldn't Unicenter stuff typically be intranets?  We can't spider those...
I can't imagine a situation where it wouldn't be used in an intranet environment. Enterprise CA products cost too much to be used in more open environments, and Unicenter isn't designed to be used for public-facing support sites.
Per discussion with bz and sicking (on separate occasions), we will not be blocking on this bug. All the alternate sane things we could attempt here carry a seemingly equal risk as shipping with what we have now, and what we have now is the cleanest approach, not to mention that it matches the HTML5 spec.

blocking2.0-
blocking2.0: ? → -
Does that mean this problem isn't going to be addressed since Unicenter has **** code or will a quirk be added?
For the initial release of Firefox 4, we'll be shipping what we have right now and trying to contact CA about updating Unicenter....
Should this bug be moved to Tech Evangelism given that we aren't making changes to Gecko?
Attached file Main part of testcase (obsolete) (deleted) — 

    
    

    
  

      
      
      
      

        Attached file
          
        Frame part of testcase (deleted)
        — 
      

    


  
Here's a simple test case.  The link works on beta9 but fails on beta10.  If you remove the <BASE TARGET="_top"> the link works on both.

    
    

    
  


  
Simplified further and changed frameset to use bugzilla link.
With a single frame it also can't find the link as long as the base target tag is include.
frame+base target tag+javascript links=not defined.

I looked through the CA files that generate the pages and that base target tag exists in hundreds of them.

        Attachment #510598 -
        Attachment is obsolete: true

    
    

    
  
CA tells me they've removed the base target tags in Service Desk 12.6. 
Also Firefox 4 will be on their supported browser list for 12.6, but not for 12.5.  

I ended up writing a simple greasemonkey script to remove the base tags on the fly.

    
    

    
  
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: