Closed Bug 1144631 Opened 5 years ago Closed 5 years ago

Secured ftp:// with authentication dialog box not working on E10S

Categories

(Core :: Networking: FTP, defect)

39 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
e10s m8+ ---
firefox42 --- fixed

People

(Reporter: wtds.trabalho, Assigned: mrbkap)

References

()

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150312150027

Steps to reproduce:

On try to access ftp:// addresses:
ftp:// not working on E10S, black page is displayed but login windows not displayed


Actual results:

On try to access ftp:// addresses:
ftp:// not working on E10S, black page is displayed but login windows not displayed


Expected results:

Normal ftp:// access with browser on E10S
ftp works for me with latest Nightly build on Mac.

Reporter, please try the build from today.  Also, what addons do you have enabled?  If any, please disable them and try ftp again.
Flags: needinfo?(wtds.trabalho)
FTP is also working for me, nightly, Mac 10.9.5.
Only E10S: The problem occurred only over authenticated FTP. For example: ftp://feitep.com.br/.
But working on non E10S mode. My version: 39.0a1 (2015-03-19)Windows 7 and Linux Mint
Flags: needinfo?(wtds.trabalho)
** Please test first on E10S ** 
Only work if first login on non-E10S windows.
I'm able to reproduce with your STR in your dupe:

ftp://demo.wftpserver.com
    Username: demo-user
    Password: demo-user

Result: no authentication dialog box, blank page.
Blocks: e10s
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: ftp:// not working on E10S → Secured ftp:// with authentication dialog box not working on E10S
Duplicate of this bug: 1145412
Assignee: nobody → mrbkap
tracking-e10s: --- → m8+
Component: Untriaged → Networking: FTP
Product: Firefox → Core
Duplicate of this bug: 1170298
Attached patch Patch v1 (obsolete) — Splinter Review
This turned out to be pretty straightforward. We had to expose nsIAuthPrompt2 through FTPChannelParent. Because we already pass the necessary information around, and the TabParent already implements nsIAuthPromptProvider, I had to change very little code.

My understanding is that Dragana isn't a peer of Necko yet, so I'm asking her for feedback. Bill, since this patch is mostly IPDL/DOM stuff anyway, would you mind reviewing? I'll verify with jduell before checkin to make sure he's cool with this, too.
Attachment #8635023 - Flags: review?(wmccloskey)
Attachment #8635023 - Flags: feedback?(dd.mozilla)
Comment on attachment 8635023 [details] [diff] [review]
Patch v1

Review of attachment 8635023 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/ftp/FTPChannelParent.cpp
@@ +471,5 @@
> +      return provider->GetAuthPrompt(nsIAuthPromptProvider::PROMPT_NORMAL,
> +                                     uuid,
> +                                     result);
> +    }
> +  }

Do we need to check if it is content process?
Attachment #8635023 - Flags: feedback?(dd.mozilla) → feedback+
(In reply to Dragana Damjanovic [:dragana] from comment #9)
> ::: netwerk/protocol/ftp/FTPChannelParent.cpp
> Do we need to check if it is content process?

We'll only ever create FTPChannelParents (or nsFTPChannels) in the parent process, so we don't have to verify here that we're not in the content process.
Comment on attachment 8635023 [details] [diff] [review]
Patch v1

Review of attachment 8635023 [details] [diff] [review]:
-----------------------------------------------------------------

::: netwerk/protocol/ftp/FTPChannelParent.cpp
@@ +464,5 @@
> +      uuid.Equals(NS_GET_IID(nsISecureBrowserUI))) {
> +    if (mTabParent) {
> +      return mTabParent->QueryInterface(uuid, result);
> +    }
> +  } else if (uuid.Equals(NS_GET_IID(nsIAuthPrompt2))) {

Might as well include nsIAuthPrompt as well?

::: netwerk/protocol/ftp/FTPChannelParent.h
@@ +19,5 @@
>  class nsILoadContext;
>  
>  namespace mozilla {
> +
> +namespace dom{

Need space.

@@ +41,5 @@
>    NS_DECL_NSIPARENTCHANNEL
>    NS_DECL_NSIINTERFACEREQUESTOR
>    NS_DECL_NSICHANNELEVENTSINK
>  
> +  FTPChannelParent(const dom::PBrowserOrId& iframeEmbedding,

aIframeEmbedding (yuck).
Attachment #8635023 - Flags: review?(wmccloskey) → review+
Comment on attachment 8636880 [details] [diff] [review]
Make FTP with auth prompts work in e10s. r=billm/dragana

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2ba3015b532b

Jason, I understand that Dragana isn't a peer. Do you want to give this a once-over or are you OK with this landing with the reviews on this bug?
Attachment #8636880 - Flags: review?(jduell.mcbugs)
Attachment #8635023 - Attachment is obsolete: true
Attachment #8636880 - Flags: review?(jduell.mcbugs) → review+
https://hg.mozilla.org/mozilla-central/rev/dedc277a5abb
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42

I can reproduce this using the same steps as in Comment 5 on latest Nightly 73.0a1 (2020-01-02) on Windows 10.
Can't reproduce on Beta 72 and Release 71.
This started happening sometime after 2019/11/08, wider pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7748cc7e9b63d86a40eb4799c0830172da579c84&tochange=f414b9e6d85710f92649566c1c6511265dadd476

Couldn't find the right issue due to 2 different wrong behaviors:

  • the download prompt will appear after accessing ftp://demo.wftpserver.com - happened during mozregression process
  • the page remains blank, there is no authentication dialog displayed - always reproducible in latest Nightly

Hey Blake, could you please take a look at this? Let me know if we should submit a new issue or re-open this one. Thanks!

Flags: needinfo?(mrbkap)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

This bug was fixed over 4 years ago and Blake is no longer with Mozilla. Please file a new bug for the recent regression.

Flags: needinfo?(mrbkap)
See Also: → 1607749
You need to log in before you can comment on or make changes to this bug.