Closed Bug 351777 Opened 19 years ago Closed 19 years ago

Domain fix up/guessing is broken.

Categories

(Core :: DOM: Navigation, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9alpha1

People

(Reporter: stephend, Assigned: Gavin)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

Build ID: 2006-09-07-10, Windows XP SeaMonkey trunk. Summary: Domain guessing/fix up is broken. In SeaMonkey trunk, if you type "domain" into the URL bar, we no longer fix up the "domain" entry into www.domain.com. This seems to be a regression from bug 323798.
Actually, this is a regresssion from bug 349419. The basic issue we run into in this bug is the following code in nsWebShell::EndPageLoad: 1078 // Skip fixup for anything except a normal document load operation on 1079 // the topframe. 1081 if (mLoadType != LOAD_NORMAL || !isTopFrame) 1082 { 1083 doCreateAlternate = PR_FALSE; 1084 } In this case, of course, mLoadType is LOAD_NORMAL_FIXUP. In my opinion, we should just back out the patch from bug 349419 and instead change LoadURI (the string version) to not propagate the fixup flag any deeper into docshell (that is, mask it off the incoming flags after we try fixup but before we create the loadinfo). This used to sorta happen, with some asserts, because ConvertLoadTypeToDocShellLoadInfo dedaults to nsIDocShellLoadInfo::loadNormal for unknown load types. But that changed with the patch for bug 349419.
Blocks: 349419
Flags: blocking1.9?
OS: Windows XP → All
Hardware: PC → All
Assignee: nobody → gavin.sharp
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.9alpha
Oh, the LOAD_NORMAL_FIXUP thing also breaks bfcache for loads done from the URL bar, since bfcache only happens for certain load types and LOAD_NORMAL_FIXUP is not one of them.
Attached patch patch per comment #1 (obsolete) — Splinter Review
This seems to fix this bug without regressing bug 349419, though I'd like to verify before asking for review.
Comment on attachment 239499 [details] [diff] [review] patch per comment #1 er, this patch is wrong.
Attachment #239499 - Attachment is obsolete: true
Attached patch patch per comment #1 (obsolete) — Splinter Review
I've tested this in a debug Firefox build, with both values of keyword.enabled.
Attachment #239502 - Flags: superreview?(bzbarsky)
Attachment #239502 - Flags: review?(cbiesinger)
Whiteboard: [patch-r?]
Comment on attachment 239502 [details] [diff] [review] patch per comment #1 Nix the whitespace changes and sr=bzbarsky
Attachment #239502 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 239502 [details] [diff] [review] patch per comment #1 + aLoadFlags = aLoadFlags & ~LOAD_FLAGS_ALLOW_THIRD_PARTY_FIXUP; I'd write this as: aLoadFlags &= ~LOAD_FLAGS_ALLOW_THIRD_PARTY_FIXUP;
Attachment #239502 - Flags: review?(cbiesinger) → review+
Attachment #239502 - Attachment is obsolete: true
mozilla/docshell/base/nsDocShell.cpp 1.816 mozilla/docshell/base/nsDocShellLoadTypes.h 1.4 mozilla/docshell/base/nsIDocShellLoadInfo.idl 1.23
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Whiteboard: [patch-r?]
Verified FIXED using trunk build 2006-09-24-09 of SeaMonkey under Windows XP.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: