87700 - The page doesn't display correctly when using a link to point an anchor in another page.

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 06-25 0.9.2 branch build

Steps to reproduce:
1. Launch browser and open Browser.
2. Create 2 html files (see attach files later) - anchor2.html and anchor.html, 
save files as shift-jis charset.  The links in anchor2.html will point to the 
anchors in anchor.html. 
3. Browse the file anchor2.html, and click the links in that file.

Result:
1. It will brings up blank page no matter the anchor name is single byte or 
double byte, and charset is marked as iso-8859-1 even the file has 
shift-jis meta-charset.  If you set the charset to shift-jis manually, then you 
will able to see the page fine.
2. If you open the click by right click mouse, using "Open Link in New Window",
then you will bring up a display OK page.
3. If you drag-drop the link to another window(default iso-8859-1) will get the 
same result as result 1.

Note:  It might cause by the fix of bug 86792, and before that bug fixed, it 
didn't point to right anchor place but the page display OK.

Comment 1

[Yuying Long]

Attachment: file anchors.html

Comment 2

[Yuying Long]

Attachment: anchor.html

Comment 3

[nhottanscp]

Bug 86792 was only for non ASCII.
ylong, is the ASCII case working in NS6.1 PR1?

Comment 4

[Yuying Long]

Yes, the ascii case worked fine on N6.1PR1 but all others point to the beginning 
of page.

Comment 5

[nhottanscp]

This does not seem to be i18n. I can reproduce this with a page below.
http://www.mozilla.org/xpfe/xulref/

It happens even after I locally backed out the change of bug 86792.

Comment 6

[nhottanscp]

I used the index page, http://www.mozilla.org/xpfe/xulref/ref_index.html.
The last time I tested, the default charset was set to Shift_JIS.
I need to find a pure ASCII case (no META on both source and target pages).

Comment 7

[nhottanscp]

Looks like this was caused by the check in of bug 82244, backed out that change
and the problem disappeared.
Cc to rpotts, radha.

Comment 8

[Frank Tang]

nhotta- can you figure out what happen if we don't back out 82244 ?

Comment 9

[nhottanscp]

The current problem is that href to anchorts in external to a document does not
work if the target page has a META charset. In fact the page shows as blank.

Below is a Japanese translated HTML 4 spec index page. Click links in that page
brings up a blank page.
http://www.asahi-net.or.jp/~bd9y-ktu/html4rec_f/index/list.html

Comment 10

[nhottanscp]

It also happens for Korean (EUC-KR).
http://trio.co.kr/webrefer/html/index/list.html

But English (ISO-8859-1) and Russian (windows-1251) do not have the problem.
http://pyramidin.wallst.ru/html401/list.html
http://www.w3.org/TR/html4/index/list.html

Comment 11

[nhottanscp]

When I get the blank page, charset menu check mark is set to ISO-8859-1. I could
be the blank page is a result of a charset conversion error.
Because the external anchor first go to the target page then scroll, it could be
the initial loading not saves the correctly charset (by META) to the cache. Then
the incorrect charset is used for the scroll to anchor causing the blank page.

Comment 12

[rpotts (gone)]

It looks like there are a couple of problems:

1. In the meta-charset reload case, nsDocShell::ScrollIfAnchor(...) is being called.
2. There are currently some bugs in ScrollIfAnchor(...) which cause it to return
indicating that the URI *was* an anchor - even though the underlying calls failed.

Unfortunately, in the meta-charset reload case, when ScrollIfAnchor(...) is
called, the DocShell's mCurrentURI attribute has *already* been updated to the
new URI.  So, this makes it look like the new URI is really just an anchor
within the current document (even though it's not :-)

To make things worse, the aWasAnchor [out] parameter is unconditionally set to
TRUE if the old and new URIs are the same...  Even if the underlying call to
nsPresShell::GoToAnchor(...) fails, aWasAnchor returns TRUE (and the method
returns NS_OK!!)

So, after ScrollToAnchor(...) silently fails, but indicates success, the load is
 completed - as if the anchor has been scrolled to...

Comment 13

[Frank Tang]

back out the first check in for 82244 can resolve this issue 

Comment 14

[Frank Tang]

fix in moz0.9.2 branch.
roy- once you land 82244 into trunk. mark this bug FIXED.

Comment 15

[Roy Yokoyama]

82244 is landed

Comment 16

[Yuying Long]

Verified fixed on 07-27 branch and 08-06 trunk build for this paticular problem.