Closed Bug 1122566 Opened 10 years ago Closed 9 years ago

e10s: ftp:// doesn't handle missing directories correctly

Categories

(Core Graveyard :: Networking: FTP, defect, P4)

x86
Windows 7
defect

Tracking

(e10s+, firefox49 fixed)

VERIFIED FIXED
mozilla49
Tracking Status
e10s + ---
firefox49 --- fixed

People

(Reporter: bemguard-bugzilla, Assigned: dragana)

References

Details

(Whiteboard: [necko-backlog])

Attachments

(1 file, 3 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150116030203 Steps to reproduce: 1) Enable e10s 2) Go to an ftp site that exists, but try to use a directory that doesn't exist eg. ftp://ftp.mozilla.org/BOGUSDIRECTORY 3) Observe Firefox UI for "Directory Not Found" popup (or any other response) Actual results: Firefox just sorts of sits there with no visible response back indicating success or failure viewing the directory. Expected results: Firefox should show some sort of response. If e10s is turned off, a popup shows up saying "Directory Not Found"
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Ever confirmed: true
Assignee: nobody → dd.mozilla
Status: NEW → ASSIGNED
Jason, can you give us an indication of how important this is for tracking purposes?
Flags: needinfo?(jduell.mcbugs)
Well, ftp:// is a dying protocol, and this is a bug only for URIs that wouldn't work anyway. But yes, we should fix it so the behavior is the same as single-process desktop. Looks like Dragana is on it...
Summary: Firefox e10s and ftp:// don't seem to play well together → e10s: ftp:// doesn't handle missing directories correctly
Attached patch fix v1 (obsolete) — Splinter Review
Attachment #8552460 - Flags: review?(jduell.mcbugs)
Flags: needinfo?(jduell.mcbugs)
See Also: → 1236381
I've tested this on the latest release(44.0) and latest Aurora(46.0a2). No pop up window appears regardless if e10s is enabled or not. User Agent: Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/44.0 Build ID: 20160123151951 User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160204004009
Jason, what's going on with this bug?
Flags: needinfo?(jduell.mcbugs)
Priority: -- → P4
Whiteboard: [necko-backlog]
Attached patch bug_1122566_v1.patch (obsolete) — Splinter Review
Attachment #8552460 - Attachment is obsolete: true
Attachment #8552460 - Flags: review?(jduell.mcbugs)
Attachment #8736315 - Flags: review?(jduell.mcbugs)
Comment on attachment 8736315 [details] [diff] [review] bug_1122566_v1.patch Review of attachment 8736315 [details] [diff] [review]: ----------------------------------------------------------------- Looks like you forgot to add the new file nsIFTPChannelParent_Internal.idl to your patch.
Attachment #8736315 - Flags: review?(jduell.mcbugs) → review-
Attached patch bug_1122566_v1.patch (obsolete) — Splinter Review
Attachment #8736315 - Attachment is obsolete: true
Attachment #8739920 - Flags: review?(jduell.mcbugs)
Flags: needinfo?(jduell.mcbugs)
Attachment #8739920 - Flags: review?(jduell.mcbugs) → review?(daniel)
The try run shows a build error on Mac OS X and I get a build error when I tried this on the current m-c ...
Attachment #8739920 - Flags: review?(daniel) → review-
Rebased and fix the try error.
Attachment #8739920 - Attachment is obsolete: true
Attachment #8747776 - Flags: review?(daniel)
Comment on attachment 8747776 [details] [diff] [review] bug_1122566_v1.patch Ship it!
Attachment #8747776 - Flags: review?(daniel) → review+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0 ID:20160506052823 CSet: 19a1743ceb2e035e571012e88d25275ce627b925
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: