HTTPS sites take a very long time to connect over wifi

RESOLVED INVALID

Status

RESOLVED INVALID
7 years ago
7 years ago

People

(Reporter: CoJaBo-Bugzilla, Assigned: sriram)

Tracking

Trunk
All
Android

Details

(Reporter)

Description

7 years ago
Fennec 8.0a1, Tested with Droid X Gingerbread.

Sites using HTTPS load significantly slower over wifi than HTTP ones (minimum 2-5 minutes as opposed to no more than a second or 2). Most of this time the browser seems to be connecting, and displays the previous page. Once the page begins to load, it displays quickly as normal.
This appears to be true of all HTTPS sites, and is particularly noticeable on gmail and bugzilla. The sites load fine in desktop Firefox connected to the same wifi connection. Turning off wifi speeds up HTTPS loading to that of HTTP over 3g. The problem never occurs on HTTP sites on any connection, or any sites on 3g connection, only HTTPS on wifi.

No console errors, and nothing looks relevant in the ddms log at warning level either.

This has been happening for some time now (at least since 7.0a), but I initially thought it was just bugzilla being unwieldy on mobile until I started using the gmail webapp and wifi more frequently.
No issues whatsoever with HTTP Secure website's on 08/13. Try clearing your cache, creating a new profile and perhaps try a separate internet connection and report back.
(Reporter)

Comment 2

7 years ago
Fennec appears to lack a clear cache option, and is there a way to create a new profile without erasing my current one?
I don't currently have access to another AP, but will try that when I can.

It'd also be helpful if theres anything else that may aid in determining the cause of this issue..
There's an addon that you can install to change profiles:
https://addons.mozilla.org/en-US/mobile/addon/mobile-profiles/

CoJaBo, where are you connecting from?
I also experience very slow loading of https resource, from a desktop linux build using a wifi connection (tested on a WEP and a WPA access points). See bug 671212 .
I have noticed this too, tying to load some Github profiles and the AMO pages. Loading just takes forever.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → 8+
Ever confirmed: true
Duplicate of this bug: 671212
I have not seen this in a while. Has anyone else? Closing until someone needs to reopen.
Status: NEW → RESOLVED
tracking-fennec: 8+ → ---
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

7 years ago
As of build 2011-08-11, I can still reproduce this 100% of the time on my device (Droid X).

Android version: 2.3.3 Gingerbread
System version: 4.596.MB810.Verizon.en.US
Baseband version: BP_C_01.09.12P
Build number: 4.5_57_DX5-26
Kernel version: 2.6.32.9-g34b306d qgd748@il93lnxdroid09 #1
ERI verison: 5
PRL version: 52220
I can still reproduce it on my galaxy tab as well. Really slow (> 1 minute) to load https://github.com/pcwalton/piranha for example. 

Loading the same page on my Nexus One is much faster. Still a bit slow overall, but much faster than the galaxy tab.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
tracking-fennec: --- → ?
Sriram - see if you can reproduce this issue. If you can we need to start looking at the code to see where the delay is happening. Try to reproduce it on desktop first (with wifi) since it will be easier to debug there.
Assignee: nobody → sriram
(Assignee)

Comment 11

7 years ago
It works fine for me on both desktop build and on galaxy tab.
I checked with mozilla-central.
Still too slow on today's nightly - on my galaxy tab (7") running Android 2.2

Faster than yesterday though. What the heck could be affecting us? Perhaps we need to get some telemetry data on the HTTP pipeline.

Updated

7 years ago
tracking-fennec: ? → 9+
I tried to reproduce on desktop Fennec and on a Samsung Galaxy S using several urls, including https://github.com/pcwalton/piranha -- no luck. Each page loaded in less than 10 seconds, with times comparable to http: sites of similar complexity.
tracking-fennec: 9+ → -
I have not seen this in a long time. Closing again.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 15

7 years ago
As of build 2011-09-21, I can still reproduce this 100% of the time on my device (Droid X).
Ok, reopening then. Not sure how you can debug this to find out what is going slow.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
tracking-fennec: - → ?
tracking-fennec: ? → -

Updated

7 years ago
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → INCOMPLETE
Should this really be marked INCOMPLETE?
(Reporter)

Comment 18

7 years ago
What other information is needed to determine the cause of this?
(In reply to CoJaBo from comment #18)
> What other information is needed to determine the cause of this?

Does it happen in the stock browser? or Opera? Can you install Mobile Tools add-on and look at the HTTP request montior. There you can see the raw requests and how long each one took. Maybe there is a problem with a particular part of the page.
(Reporter)

Comment 20

7 years ago
This is a bug in the Droid X stock Gingerbread firmware (all versions). It affects all HTTPS connections when wifi is active-
The Android browser seems to fall back to loading the page from cache as the bug only presents on not-previously-visited pages or after clearing the cache; 
Opera did not appear to be affected, but OTA updates only download over 3G, Google account data (Gmail, calendar entries) will (silently) postpone syncing until wifi connection is dropped, Maps will not load map tiles for non-previously-viewed areas until wifi is turned off, and Navigation will stall on "waiting for directions" until out of wifi range. The cause isn't obvious, but it happens 100% of the time- it is quite strange, then, this would have gone unnoticed by Verizon/Motorola. It might be worth noting in release notes or something?
The work-around is to switch to CyanogenMod, which recently added Droid X support- wifi works flawlessly in this case.
(Reporter)

Comment 21

7 years ago
I suspect this would have to be specific to some network environment/setting (I did not have access to another network when testing, and I am no longer running the firmware so cannot check in the future).
For reference, in case someone does happen across this issue again, the wifi network is 802.11n 2.4Ghz, WPA2 secured, on a Netgear N600 WNDR3700 router (firmware version V1.0.7.98NA) configured in "Up to 130Mbps" mode, WMM and QoS enabled, using Google Public DNS. No proxy or filtering is used, and the issue is not present on any other device, only on the Droid X with stock Gingerbread firmware. Stock Froyo and CyanogenMod firmware on the same device are not affected.

Updated

7 years ago
Resolution: INCOMPLETE → INVALID
You need to log in before you can comment on or make changes to this bug.