Closed Bug 347897 Opened 14 years ago Closed 13 years ago

view source on feeds preview shows contents of wrong page

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect, critical)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: darin.moz, Assigned: sayrer)

References

()

Details

(Keywords: verified1.8.1.1)

Attachments

(1 file)

Using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060808 BonEcho/2.0b1

Steps:
1- navigate to http://news.com.com/2547-1_3-0-20.xml
2- click on a link
3- click back button
4- do view source

Problem:
Source is shown for the link that you clicked on instead of for the feed you are viewing.
There must be another step involved somewhere, because with the same build and OS, I get the source for the feed when I go back, no matter which link I follow.
Weird, I cannot reproduce it either.  I wonder what other step I did to be able to reproduce the problem so easily this morning :-(
I can see it. OS 10.4 / Trunk 09/13/2006.
100% reproducible here. Easiest way to repro is hitting back then forward: you get the source of this page.

WinXP
Yeah, I still have this.
I also have this happening.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

1) Visit an feed (checked an rss or atom). ie: http://googleblog.blogspot.com/atom.xml

2) View the source: displays the xml source for the feed.

3) Click on a link in side the feed. 

4) View the source: displays the (x)html source for the page.

5) Click back button.

6) View the source: displays the (x)html source of the page you were just at. It should be displaying the XML source from the feed.
Just so we're all on the same page, this is the code in question from viewSource.js:

var PageLoader = getBrowser().webNavigation.QueryInterface(pageLoaderIface);

try {
...
  // Load the page using the page descriptor rather than the URL.
  // This allows the content to be fetched from the cache (if
  // possible) rather than the network...
  PageLoader.loadPage(arg, pageLoaderIface.DISPLAY_AS_SOURCE);
...
}
catch (ex) {
  // Ignore the failure.  The content will be loaded via the URL
  // that was supplied in arg[0].
}

AFAIT LoadPage takes the right document here (which probably isn't cached considering the way feed preview works), but instead of throwing loads the document of the previous SHEntry.
Component: RSS Discovery and Preview → Embedding: Docshell
Product: Firefox → Core
QA Contact: rss.preview → docshell
Version: 2.0 Branch → Trunk
> AFAIT LoadPage takes the right document here 

Really?  I used the following steps:

1)  Start browser
2)  Load http://news.com.com/2547-1_3-0-20.xml
3)  Back
4)  Forward
5)  View source

In LoadPage, the URI of the incoming SHentry is <http://www.mozilla.org/projects/minefield/>.

Checking what GetCurrentDescriptor is returning, it looks like at the point when we call GetCurrentDescriptor the history entry of the docshell is the entry for the document in bfcache.

So what the _heck_ is RSS doing to cause this situation?  ;)  This should _so_ not be happening.  Like "code not designed to handle this" not happening.
Severity: normal → critical
Flags: blocking1.9?
Flags: blocking1.8.1.1?
OS: Windows XP → All
Hardware: PC → All
OK.  So when loading the RSS feed from history I first hit nsDocShell::EndPageLoad, called when the HTTP channel is removed from the loadgroup.  _Then_ I hit nsDocShell::Embed when the jar channel calls OnStartRequest.

That's backwards.  So we first null out mLSHE in EndPageLoad, then have nothing to set mOSHE to in Embed.
I didn't actually inpect the SHEntry, just the incoming content document...
  handleResult: function FC_handleResult(result) {

(in FeedConverter.js) never sets a loadgroup on the channel it opens.  That's the problem.
Back to where this bug came from.  This is so not a core Gecko issue.  ;)
Component: Embedding: Docshell → RSS Discovery and Preview
Flags: blocking1.9?
Product: Core → Firefox
QA Contact: docshell → rss.preview
Just to clarify my nomination, this code is putting the docshell in an inconsistent and unexpected state.  I can't guarantee that it doesn't crash, isn't exploitable, etc.
Flags: blocking-firefox3?
Attachment #245976 - Flags: review?(mano)
Assignee: nobody → sayrer
Comment on attachment 245976 [details] [diff] [review]
set the loadGroup

interactive r=mano.
Attachment #245976 - Flags: review?(mano) → review+
Checking in FeedConverter.js;
/cvsroot/mozilla/browser/components/feeds/src/FeedConverter.js,v  <--  FeedConverter.js
new revision: 1.22; previous revision: 1.21
done
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Land this on branch too?
Attachment #245976 - Flags: approval1.8.1.1?
Flags: blocking1.8.1.1? → blocking1.8.1.1+
Comment on attachment 245976 [details] [diff] [review]
set the loadGroup

approved for 1.8 branch, a=dveditz for drivers
Attachment #245976 - Flags: approval1.8.1.1? → approval1.8.1.1+
Whiteboard: [checkin needed (1.8 branch)]
Checking in FeedConverter.js;
/cvsroot/mozilla/browser/components/feeds/src/FeedConverter.js,v  <--  FeedConverter.js
new revision: 1.1.2.21; previous revision: 1.1.2.20
done
Keywords: fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)]
v.fixed on 1.8.1 branch and Trunk/1.9 with 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.1pre) Gecko/20061128 BonEcho/2.0.0.1pre
and
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a1) Gecko/20061128 Minefield/3.0a1

View->Page Source shows the proper source for feed xml page.
Status: RESOLVED → VERIFIED
Depends on: 363740
Flags: blocking-firefox3?
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.