User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24 Safari/535.1 Steps to reproduce: 1. visit http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm - In this test, the page in the iframe is navigated to through a script operation (document.location.href=). The correct navigation type should be TYPE_NAVIGATE. Right now it's detected as TYPE_RESERVED. 2. visit http://w3c-test.org/webperf/tests/approved/test_timing_attributes_order.htm - It has the same failure as above when detecting the transition type. 3. visit http://w3c-test.org/webperf/tests/approved/test_timing_client_redirect.htm - The page is navigated to using a client meta-refresh redirect, so it's navigation type should be TYPE_NAVIGATE instead of TYPE_RESERVED. 4. http://w3c-test.org/webperf/tests/approved/test_timing_server_redirect.htm - This is a server redirect within the same origin so the redirection count should be 1. Right now it's returnning 0. Actual results: 1, 2, 3: navigation.type is TYPE_RESERVED 4: redirectCount is 0 Expected results: 1, 2, 3: navigation.type is TYPE_NAVIGATE 4: redirectCount is 1

Tests and 2 small changes in implementation: - Change in navigation type conversion - Added field to store redirect count Related W3C tests now pass

Comment on attachment 543152 [details] [diff] [review] Tests and fixes for navigation type and redirect count Btw, do we have tests for location.replace handling? If I read the code correctly, that would end up using LOAD_STOP_CONTENT_AND_REPLACE. Does the spec say anything about replace?

http://hg.mozilla.org/mozilla-central/rev/df4ec91d0b0a I'll let Igor answer the question in the last comment.

No, we don't have tests for location.replace and if load type is LOAD_STOP_CONTENT_AND_REPLACE we will get wrong navigation type, as spec says 'TYPE_NAVIGATE: Navigation started by ... initializing through a script operation other than the ones used by TYPE_RELOAD and TYPE_BACK_FORWARD' We need a test and follow-up bug for that. thanks.

(In reply to comment #4) > We need a test and follow-up bug for that. Could you please file the bug. It should be easy to fix that one :)