16782 - [DOGFOOD]Post Data forgotten when traversing thro' Session History.

Status: VERIFIED DUPLICATE of bug 17685

(Core :: Networking, defect, P3)

Description

[cpratt]

Build ID: 1999101908
Platform: Windows NT

To reproduce:
(These instructions are probably overly elaborate - but if followed, they
reproduce this problem every time.)
- Launch apprunner
- Set your home page to a local file that contains a link to my.yahoo.com
- Visit My Yahoo! (my.yahoo.com)
- Log in but do NOT tick the box to save that info
- When Wallet dialogs appear, OK them, enabling wallet & saving the form values
- Quit the browser
- Launch apprunner
- Follow the link to my.yahoo.com
- Click the Sign in button (the form should be prefilled)
- Follow a link on your My Yahoo! page
- Click Back

Result: You go 'back' to a page you haven't visited before:
http://login.yahoo.com/config/login (instead of my.yahoo.com).

Expected result: You return to the My Yahoo! page.

I'm not sure if this is a cookie or RDF/history problem; please reassign as
necessary. Thanks!

Comment 1

[Stephen P. Morse]

Bug has nothing to do with wallet, single-signon, or cookies.  This has to be
an rdf/history issue.  Here is a simplified set of steps to reproduce the
problem.

- If you don't already have a yahoo account, get one using a 4.x browser so as
not to store any data in 5.0 cookies or other permanent files.
- launch 5.0 browser
- go to my.yahoo.com
- fill in username and password
- click on link to sign in
- if single-signon dialog appears, dismiss it by pressing cancel
- when my-yahoo page comes up, press any link
- when you get to the linked page, press back

result: you get to a page you did not expect.  One time I got to the yahoo login
page (as reported above).  Another time I got to mozilla.org.

Reassigning to rjc to investigate for rdf/history problem.

Comment 2

[Robert John Churchill]

This looks like a "session history" bug, not a "global history" bug. Reassigning
to Radha.

Comment 3

[Radha on family leave (not reading bugmail)]

Know what the problem is. Shall fix soon.

Comment 4

[Radha on family leave (not reading bugmail)]

*** Bug 16704 has been marked as a duplicate of this bug. ***

Comment 5

[Radha on family leave (not reading bugmail)]

This is going to need some API additions in webshell  which is currently under
redesign. Moving to M12.

Comment 6

[cpratt]

*** Bug 17430 has been marked as a duplicate of this bug. ***

Comment 7

[cpratt]

*** Bug 17933 has been marked as a duplicate of this bug. ***

Comment 8

[Paul MacQuiddy]

Actually, I'm pretty sure bug 17430 is a different problem. Bug 17430, and bug
17933, have to do with pages partially loading and not going into session
history. Regardless, let's let radha figure this out.

Comment 9

[Radha on family leave (not reading bugmail)]

None of these bugs 17430, 17933, 16782 are duplicates of each other.

17430  - For partially loaded pages not included in SH. This is a dup of 18038
17933 - For intl pages, Back/Forward buttons don't work properly. This **is a
well known** problem in intl page loading. There is some work needs to be done
by the intl team. So don't close this out as duplicate. 15873 is a dup of this
bug.
16782(the current bug) - This is for pages with post data. This bug is a dup of
17685. I'm marking it so.

*** This bug has been marked as a duplicate of 17685 ***

Comment 10

[bobj]

17933 - **is a NOT well known** problem as commented in related bugs.
This is correct behavior.

When loading a page (w/out HTTP charset attribute), we use a fallback charset
and convert to Unicode accordingly.  If the parser detects any type of META
tag it will use the observer interface to notify any META handlers. If the
META charset handler tag specifies a charset which is different from the
fallback, the page must be reloaded, so the data can be correctly converted
to Unicode.

Comment 11

[ckritzer (gone)]

Marking VERIFIED DUPLICATE per radha's comments.

Comment 12

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.