Pages not loading completely requiring a force-refresh

RESOLVED FIXED in Firefox 31

Status

()

defect
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: RyanVM, Assigned: mayhemer)

Tracking

({regression})

Trunk
mozilla32
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox31 fixed, firefox32+ fixed)

Details

(Whiteboard: [qa-] )

Attachments

(1 attachment)

Since I updated my local build to m-c tip this morning, I've had many instances of pages not loading or loading incompletely. Only a force-refresh has worked.

I wasn't experiencing this problem with an m-c tip build from yesterday's round of merges performed by myself. Looking at what has landed on m-c since, bug 1014394 seems the most likely candidate. I'll backout locally to try and confirm.
Hmm.. something our infra would not catch?  Weird.  Any URLs or just "anything"?  Going to try my self.  Thanks for the report.
(In reply to Honza Bambas (:mayhemer) from comment #1)
> Hmm.. something our infra would not catch?  Weird.  Any URLs or just
> "anything"?  Going to try my self.  Thanks for the report.

bugzilla.mozilla.org bug pages and addons.mozilla.org definitely affected.

To reproduce, you'll likely need to use yesterday's nightly to first load those sites. Next, update to today's nightly then revisit those pages.

After a forced reload (i.e. ctrl + F5) the specific page seems to no longer exhibits the issue. This is, of course, a problem if you have a lot of affected visited pages.
OK, got it, this is actually regression from bug 995801.  Not related to 1014394 at all.  Anyway, it just uncovers bug in cache2 code, or actually http channel code that badly handles the missing sec info.

Going to provide a patch.
Assignee: nobody → honzab.moz
Blocks: 995801
No longer blocks: 1014394
Status: NEW → ASSIGNED
Posted patch v1Splinter Review
Patrick, please one quick review on this simple and urgent patch.  Thanks.

The problem was that when we failed to open the cache entry's sec info, not all conditional headers were removed.  So, the channel rejected correctly the entry but left the "If-None-Match" request header.  It was then getting 304 but provided no content (304 empty body actually), since there were (correctly) no cache entry to read from.
Attachment #8430931 - Flags: review?(mcmanus)
Flags: in-testsuite?
Attachment #8430931 - Flags: review?(mcmanus) → review+
I cherry-picked this to m-c so we could get a nightly respin.
https://hg.mozilla.org/mozilla-central/rev/b85b57f05fda
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment on attachment 8430931 [details] [diff] [review]
v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 995801 uncovered it
User impact if declined: Needed to uplift the patch in bug 995801
Testing completed (on m-c, etc.): landed last week on m-c
Risk to taking this patch (and alternatives if risky): low, as I understand it
String or IDL/UUID changes made by this patch: none
Attachment #8430931 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 1018490
Attachment #8430931 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.