121481 - forget datas

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Tom Jac]

go to
http://www.stabikat.de/
make a search, i.e. "test"  click [Suchen]

click on a result... doesnt work:
------------
Vergessen
Ihre Aktion bezieht sich auf ein inzwischen nicht mehr vorhandenes Suchergebnis.
------------

netscape 4.7 works.

Comment 1

[Boris Zbarsky [:bzbarsky]]

% ping www.stabikat.de
PING www.stabikat.de (194.94.133.19) from 10.0.0.2 : 56(84) bytes of data.
From ar-huberlin1.g-win.dfn.de (188.1.20.2): Destination Host Unreachable
From ar-huberlin1.g-win.dfn.de (188.1.20.2): Destination Host Unreachable
From ar-huberlin1.g-win.dfn.de (188.1.20.2): Destination Host Unreachable

--- www.stabikat.de ping statistics ---
10 packets transmitted, 0 packets received, +3 errors, 100% packet loss

not very helpful.... can you actually access the site?  What mozilla build are
you using?

Comment 2

[Tom Jac]

Yes I've got access now (13:24):

http://www.stabikat.de/

When did you tried it, at night? Perhaps they made a backup? (It's a library
catalogue: Stately Library Berlin, on of the largest librarys in Germany.)  If
you need translation from German it would be a pleasure to help - if I can.
Thanks a lot.

Comment 3

[Tom Jac]

I use build 2001122106 (0.9.7) for windows and linux.

Comment 4

[Doron Rosenberg (IBM)]

http://stabikat.staatsbibliothek-berlin.de:8080/CMD?ACT=SRCHA&IKT=1016&SRT=YOP&TRM=test

Seeing this too. Click on any link

Comment 5

[Asa Dotzler [:asa]]

->Necko

Comment 6

[neeti]

This works for me on windows2000

Comment 7

[neeti]

cc'ing darin

Comment 8

[Darin Fisher]

-> badami for investigation

Comment 9

[Vinay Badami]

This does not seem to be a networking bug.
When i do the following 
1. go to http://www.stabikat.de/
2. make a search, i.e. "test"  click [Suchen]
3. Open the first result in a new window,

With IE the URL for the first result is 
http://sbbweb1.sbb.spk-berlin.de:8080/DB=1/FKT=1016/FRM=test/IMPLAND=Y/LNG=DU/SET=1/SID=f639c1ac-43/SRT=YOP/TTL=1/SHW?FRST=1
However, when i do it with Mozilla,
http://sbbweb1.sbb.spk-berlin.de:8080/SET=1/TTL=1/SHW?FRST=1.

If i do try to open the IE URL in Mozilla, I get the correct response.
So the problem seems to be that we seem to be forgetting our base URL or href.

Comment 10

[Darin Fisher]

badami: two possible explanations that come to mind:

1) relative URL resolution problem - mozilla bug
2) relative URL resolution problem - server violating RFC 2396
3) server not sniffing mozilla useragent correctly, sending mozilla garbage.

if it's a problem with relative URL resolution, then we need to identify the
problem so we can either fix it on our end or provide the evangelism team with
suitable information.  likewise, if it's problem 3.

Comment 11

[Nivedita (gone)]

This problem is occuring because base href is ignored when it occurs within the 
body tag and not the head tag for a form. Hence for a relative actionURL, the 
generated actionurl during the submit is not relative to the base href url but 
is with respect to the document url.

I observe that the in the nsHTMLFormElement::GetActionURL, which calls 
mDocument->GetBaseURL, returns a baseurl value but which is not the base href 
value. This is because the baseurl is not getting updated with base href value 
in the mDocument.

I have attached the test case, which verifies that the base href tag occuring 
in the body is ignored for a form.

Comment 12

[Nivedita (gone)]

Attachment: .tar.gz file having the testcase

test case for the comment 11

Comment 13

[Tanu Mutreja]

Attachment: Patch to fix it...

This is Parser bug, in fact not a bug but a better way to deal with malformed
HTML, where BASE tag is appearing outside HEAD. Though HTML specs recommends it
to be inside HEAD but the patch provides a fix to handle it in the way other
browsers do.

Comment 14

[Tanu Mutreja]

CC'ing Harish for review and comments.

Comment 15

[harishd]

Could you exploit mFlags memeber instead? That is, do something like

Index: nsHTMLContentSink.cpp
===================================================================
RCS file: /cvsroot/mozilla/content/html/document/src/nsHTMLContentSink.cpp,v
retrieving revision 3.526
diff -u -r3.526 nsHTMLContentSink.cpp
--- nsHTMLContentSink.cpp       6 Mar 2002 07:46:31 -0000       3.526
+++ nsHTMLContentSink.cpp       13 Mar 2002 19:33:52 -0000
@@ -195,6 +195,7 @@
 #define NS_SINK_FLAG_FRAMES_ENABLED   0x10
 #define NS_SINK_FLAG_CAN_INTERRUPT_PARSER 0x20 //Interrupt parsing when
mMaxTokenPro
exceeded
 #define NS_SINK_FLAG_DYNAMIC_LOWER_VALUE 0x40 // Lower the value for
mNotificationIn
TokenProcessingTime
+#define NS_SINK_FLAG_IS_BASE_HREF_SET 0x80 // Lower the value for
mNotificationInter
enProcessingTime

 #define NS_DELAY_FOR_WINDOW_CREATION  500000  // 1/2 second fudge factor for window
 #define NS_MAX_TOKENS_DEFLECTED_IN_LOW_FREQ_MODE 200 //200 determined
empirically to
ser response without
@@ -4150,12 +4151,13 @@
   rv = NS_NewURI(getter_AddRefs(baseHrefURI), aBaseHref, nsnull);
   if (NS_FAILED(rv)) return;

-  if (nsnull == mBody) {  // still in real HEAD
+  if ((mFlags & NS_SINK_FLAG_IS_BASE_HREF_SET) || nsnull == mBody) {  // still
in re
     rv = mDocument->SetBaseURL(baseHrefURI); // The document checks if it is
legal t

     if (NS_SUCCEEDED(rv)) {
       NS_RELEASE(mDocumentBaseURL);
       mDocument->GetBaseURL(mDocumentBaseURL);
     }
+    mFlags |= NS_SINK_FLAG_IS_BASE_HREF_SET;
   }
   else {  // NAV compatibility quirk

Comment 16

[benc]

->parser + QA

Please update the component (and QA) when you take bugs out of networking...

Comment 17

[Tanu Mutreja]

Attachment: Incorporated Harish's suggestions

Comment 18

[harishd]

Comment on attachment 74077 [details] [diff] [review]
Incorporated Harish's suggestions

r=harishd [ provided IE exhibits the same behavior ]

Comment 19

[Tanu Mutreja]

IE is taking the last BASE HREF appearing in HTML document irrespective of 
the fact whether it's appearing in HEAD or BODY. I feel by giving preference to 
the BASE appearing in HEAD over the one appearing in BODY, we are favoring the 
HTML specifications more closely. 

Comment 20

[Vinay Badami]

Reassigning to Tanu since she wrote up the patch.

Comment 21

[Johnny Stenback (:jst)]

Comment on attachment 74077 [details] [diff] [review]
Incorporated Harish's suggestions

sr=jst

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 74077 [details] [diff] [review]
Incorporated Harish's suggestions

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 23

[Vinay Badami]

Fixed with checkin
C:\mozilla\content\html\document\src>cvs commit
cvs commit: Examining .
Checking in nsHTMLContentSink.cpp;
/cvsroot/mozilla/content/html/document/src/nsHTMLContentSink.cpp,v  <--  nsHTMLC
ontentSink.cpp
new revision: 3.528; previous revision: 3.527
done

Comment 24

[John Keiser (jkeiser)]

Attachment: Patch for harish

This patch makes forms honor _base_href, a necessity when Harish implements
with bug 141537

Comment 25

[harishd]

After investigating bug 141537 it turns out that the fix in this bug breaks
backwards compatibility. JKeiser and I discussed about it and have a solution in
hand.

REOPENING

Comment 26

[John Keiser (jkeiser)]

Fixed with bug 141537.