Closed
Bug 605077
Opened 14 years ago
Closed 14 years ago
Gmail Inbox not loading in standard view
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
status1.9.2 | --- | .13-fixed |
status1.9.1 | --- | unaffected |
People
(Reporter: ahoza, Assigned: bsterne)
References
Details
Attachments
(2 files, 1 obsolete file)
25.11 KB,
image/png
|
Details | |
881 bytes,
patch
|
jst
:
review+
jst
:
approval2.0+
dveditz
:
approval1.9.2.13+
|
Details | Diff | Splinter Review |
Device: Nokia N900 BuildID: Mozilla /5.0 (Maemo;Linux armv7l;rv:2.0b8pre)Gecko/20101017 Firefox/4.0b8pre Fennec /4.0b2pre Device: HTC Desire BuildID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b8pre) Gecko/20101017 Firefox/4.0b8pre Fennec /4.0b2pre Steps to reproduce: 1. Start Fennec. 2. Load gmail.com and enter credentials. Expected results: Gmail Inbox page is displayed. Actual results: "This is taking longer than usual" is displayed (see atached screenshot) If one chooses "basic HTML view" link in that page, Gmail Inbox loads. Note: Gmail Inbox page loads properly, in standard view, when using native browser. This should happen with Fennec as well.
Comment 1•14 years ago
|
||
reproducible already on 20101015
Comment 2•14 years ago
|
||
regressed at central 5b8582013988->5fcb86d51691, mobile d46fdbdbe45f->d46fdbdbe45f (sic)
Comment 3•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5b8582013988&tochange=5fcb86d51691
Comment 4•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ed24c21e6497&tochange=5fcb86d51691 bug 581226 bug 561051
Assignee | ||
Comment 6•14 years ago
|
||
Can you put a breakpoint in nsDSURIContentListener::CheckFrameOptions and see where you return and what is returned?
Comment 7•14 years ago
|
||
(In reply to comment #6) > Can you put a breakpoint in nsDSURIContentListener::CheckFrameOptions and see > where you return and what is returned? After beginning to load gmail I get one return from http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#311 and then 4 returns http://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDSURIContentListener.cpp#341.
Comment 8•14 years ago
|
||
I didn't quite get what is the essential difference here but when looking at the changes http://hg.mozilla.org/mozilla-central/rev/f5c0015afe0e and http://hg.mozilla.org/mozilla-central/rev/5fcb86d51691 I noticed the while-loop having a different form in the condition. With this "older" form of the condition gmail inbox gets loaded ok.
Attachment #484638 -
Flags: review?(jst)
Updated•14 years ago
|
Attachment #484638 -
Flags: review?(bsterne)
Comment 9•14 years ago
|
||
>- while (NS_SUCCEEDED(curDocShellItem->GetParent(getter_AddRefs(parentDocShellItem)) &&
>- parentDocShellItem)) {
Here's the problem: the NS_SUCCEEDED call includes the && parentDocShellItem condition. Guh.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #9) > Here's the problem: the NS_SUCCEEDED call includes the && parentDocShellItem > condition. Guh. Yep. Pekka, can you test this patch to see if it fixes the Gmail problem?
Attachment #484638 -
Attachment is obsolete: true
Attachment #484638 -
Flags: review?(jst)
Attachment #484638 -
Flags: review?(bsterne)
Assignee | ||
Comment 11•14 years ago
|
||
I'm curious why this only shows up on Fennec, but I suspect Josh is right and hopefully the patch fixes us there.
Updated•14 years ago
|
Attachment #484695 -
Flags: review+
Attachment #484695 -
Flags: approval2.0+
Assignee | ||
Comment 12•14 years ago
|
||
This is the right fix. The condition is wrong for both Firefox and Fennec but we survive on Fennec because we hit the break after finding a chrome docshell. Since we don't find such a chrome docshell on Fennec, we enter the while loop an additional time with parentDocShell == null so we can't find a topDoc and thus return false blocking the frame from loading. Thanks for catching this. http://hg.mozilla.org/mozilla-central/rev/2ccdeb31509b
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•14 years ago
|
||
(In reply to comment #12) > This is the right fix. The condition is wrong for both Firefox and Fennec but > we survive on Fennec Should have read "survive on Firefox".
Comment 14•14 years ago
|
||
(In reply to comment #12) > This is the right fix. > ... > http://hg.mozilla.org/mozilla-central/rev/2ccdeb31509b Yes, this works. Thanks.
Comment 15•14 years ago
|
||
Verified on Build: Mozilla/5.0(Android; Linux armv7l; rv:2.0b8pre) Gecko/20101021 Firefox/4.0b8pre Fennec/4.0b2pre
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Assignee: nobody → bsterne
Component: General → DOM: Core & HTML
Product: Fennec → Core
QA Contact: general → general
Target Milestone: --- → mozilla2.0b7
Comment 16•14 years ago
|
||
Comment on attachment 484695 [details] [diff] [review] patch (per comment 9) I assume we also need this on 1.9.2 since we just took the regressing patch.
Attachment #484695 -
Flags: approval1.9.2.13?
Comment 17•14 years ago
|
||
Comment on attachment 484695 [details] [diff] [review] patch (per comment 9) Approved for 1.9.2.13, a=dveditz
Attachment #484695 -
Flags: approval1.9.2.13? → approval1.9.2.13+
Comment 18•14 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5cb659ed04a0
status1.9.2:
--- → .13-fixed
status1.9.1:
--- → unaffected
You need to log in
before you can comment on or make changes to this bug.
Description
•