323537 - Cached page opened in new window doesn't get feed autodiscovery

Status: RESOLVED FIXED

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

Description

[Peter van der Woude [:Peter6]]

repro:
1. Open http://pvanderwoude.com/feeds/rss_link.html in a new window
-result, the rss feed is often not detected
2. Reload
-result, the rss feed is detected

for both trunk/branch (this occurs for post-1.5 build)

For some very obscure reason the RSS-link from the above page is not allways detected (and displayed in the locationbar) when this page is opened into a new window (via a link).

It works if the page is opened into a new tab.
It works when the url is entered in the locationbar
It works with a crisp new profile

It fails often with a used profile.
It sometimes fails in -savemode, sometimes not

It always works when you reload the page.

There seems that this is not caused by an extension

Comment 1

[Peter van der Woude [:Peter6]]

any idea what's going on here Phil ?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

I think I've noticed something similar to this. Loading planet.mozilla.org as the homepage would result in the live bookmark indicator not being present, but it would appear after a reload.

Comment 3

[Shayne Jewers]

dunno if this helps, but I get these JS Console errors when I repro the bug:

Error: this.menuCommanders has no properties
Source file: chrome://greasemonkey/content/browser.js
Line: 234
 ----------
Error: Components is not defined
Source file: chrome://fgupdater/content/fgupdater.js
Line: 11
 ----------
Warning: assignment to undeclared variable abLoad
Source file: chrome://adblock/content/adblock.xml
Line: 17
 ----------
Warning: Key event not available on GTK2: key="d" modifiers="accel,shift"
Source file: chrome://browser/content/browser.xul
 ----------
Warning: Key event not available on GTK2: key="b" modifiers="accel,shift"
Source file: chrome://browser/content/browser.xul
 ----------
Warning: Key event not available on GTK2: key="f" modifiers="accel,shift"
Source file: chrome://browser/content/browser.xul
 ----------
Warning: Key event not available on GTK2: key="a" modifiers="accel,shift"
Source file: chrome://browser/content/browser.xul
 ----------
Error: stopIsValid is not defined
Source file: chrome://fasterfox/content/listener-fasterfox.js
Line: 60

Comment 4

[Phil Ringnalda (:philor)]

In 2005080921 (the last build I have before the icon moved to the addressbar), it works fine; in 2005081220 (the first build I have after it moved) it works when the page isn't cached, but once you've loaded it once so it's cached, then it fails until you clear your cache.

My first guess is usually wrong, but I'd guess that's the sort of race condition we usually paper over with a nice SetTimeout.

Comment 5

[Peter van der Woude [:Peter6]]

happens to non-cached pages aswell (both on trunk/branch)

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)

http://pvanderwoude.com/feeds/firefoxfeed.xml (linked by http://pvanderwoude.com/feeds/rss_link.html) doesn't return Cache-Control:max-age header nor Expires: header to HTTP GET with no-cache.
> http://pvanderwoude.com/feeds/firefoxfeed.xml
> GET /feeds/firefoxfeed.xml HTTP/1.1
> Host: pvanderwoude.com
(snip)
> Cache-Control: no-cache
>
> HTTP/1.x 200 OK
> Date: Mon, 27 Feb 2006 19:12:55 GMT
> Server: Apache
> Vary: Host
> Last-Modified: Mon, 27 Feb 2006 16:35:36 GMT
> Etag: "39ac5-800-4cdd4600"
> Accept-Ranges: bytes
> Content-Length: 2048
> Keep-Alive: timeout=2, max=100
> Connection: Keep-Alive
> Content-Type: application/xml
And about:cache(disk cache) for the URI becomes: (expires after 16 minutes)
>           Key: http://pvanderwoude.com/feeds/firefoxfeed.xml
>     Data size: 2048 bytes
>   Fetch count: 1
> Last modified: 2006-02-28 04:12:56
>       Expires: 2006-02-28 04:28:37
So if your cache option is "When the page is out of date" ( browser.cache.check_doc_frequency=3 ), you are possibly seeing phenomenon described in Bug 328605 when RSS (Case-2 in Bug 221036 Comment #13).
(If link is clicked again within 16 minutes, it is read from cache.)

See http://www.mozilla.org/projects/netlib/http/http-debugging.html and get HTTP protocol log, and attach log file to this bug(mime-type=text/plain;).
Log for next four cases are required(log with no extention=safemode).
 (1) Shift+Reload(access with no-cache)
 (2) Reload(access with If-Modified-Since: usually)
 (3) Normal load in a new tab (You say problem never occur)
     (link click or bookmark. Read from cache if not expired.)
 (4) Normal load in a new window (You say problem may occur)
     (link click or bookmark. Read from cache if not expired.)
And check about:cache(both memory cache and disk cache for URI after each step.

Note: Bug 328605 can not explain next in your case.
> 1. Open http://pvanderwoude.com/feeds/rss_link.html in a new window
> -result, the rss feed is often not detected  
But
> It works if the page is opened into a new tab.
> It works when the url is entered in the locationbar
Are there any JavaScript errors relate to the RSS in JavaScript Console?
Difference between "new window" and "new tab"/"location bar" is whether cache is expired or not, isn't it?

Comment 7

[Peter van der Woude [:Peter6]]

(In reply to comment #6)
>  (1) Shift+Reload(access with no-cache)
>  (2) Reload(access with If-Modified-Since: usually)
>  (3) Normal load in a new tab (You say problem never occur)
>      (link click or bookmark. Read from cache if not expired.)
>  (4) Normal load in a new window (You say problem may occur)
>      (link click or bookmark. Read from cache if not expired.)
I set up FF with 1 bookmarks (http://pvanderwoude.com/feeds/rss_link.html)
and the same page as homepage.
and ran all 4 cases in -safe-mode (att. coming)

Comment 8

[Peter van der Woude [:Peter6]]

Attachment: case 1

Comment 9

[Peter van der Woude [:Peter6]]

Attachment: case 2

Comment 10

[Peter van der Woude [:Peter6]]

Attachment: case 3

Comment 11

[Peter van der Woude [:Peter6]]

Attachment: case 4

Comment 12

[WADA:World Anti-bad-Duping Agency]

No difference between case-3 and case-4. In both cases, data is read from cache because cached data is not expired.
(This is because "Heuristic Expiration" is 16 minutes and access is done within 16 minutes after last Reload.)

> 0[ec4400]: nsHttpResponseHead::MustValidate ??
> 0[ec4400]: no mandatory validation requirement
> 0[ec4400]: Not validating based on expiration time
> 0[ec4400]: CheckCache [this=xxxxxxxx doValidation=0]
> 0[ec4400]: nsHttpChannel::ReadFromCache [this=20e3008] Using cached copy of:
>            http://pvanderwoude.com/feeds/rss_link.html

Peter van der Woude, what is your expectation on cache exipration time (corresponds to Cache-Control:max-age=) when server is lazy on supplying cache expiration time information to client?

Comment 13

[Peter van der Woude [:Peter6]]

(In reply to comment #12)

> Peter van der Woude, what is your expectation on cache exipration time
> (corresponds to Cache-Control:max-age=) when server is lazy on supplying cache
> expiration time information to client?
> 
You are overasking me, sorry.
I have no idea what you are talking about / asking from me.

Comment 14

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #12)
Correction. Sorry for spam.

Comment #12 is not for the RSS feed(<link rel="alternate" type="application/rss+xml"). So original problem(comment #0) is still unclear.
However, Comment #12 is applicable to the HTML and RSS accessed by clicking link, and if the HTML page or the RSS feed is updated, situation described in Bug 328605  may occur.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #13)
> You are overasking me, sorry.
No, no, It's my fault.
I confused RSS link click case and Live bookmark case, and confused Live bookmark of Seamonkey and Live bookmark of Firefox.

Since server doesn't return Cache-Control:max-age nor Expires:, cache expiration becomes "Heuristic Expiration" and is set to 16 minutes by FF as I wrote in comment #6(See Bug 328605 and bugs pointed in it for "Heuristic Expiration").
So cached data is used when link click within 16 minutes after Reload.

When Live bookmark, situation is slightly more complex, because Live Bookmark automatically checks with some interval.
But I still can't find where to set these options when Firefox.
Do you know update freequency settings in your Firefox of live bookmark for http://pvanderwoude.com/feeds/firefoxfeed.xml?
(Live bookmark can also have relation to "Not OK when new window" but "No problem when new tab").

Comment 16

[:Gavin Sharp [email: [e-mail]]]

I'm not entirely sure that this is what you're looking for, but the live bookmark update interval is controlled by the browser.bookmarks.livemark_refresh_seconds pref. The default is 1 hour, the minimum is 1 minute.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/components/bookmarks/src/nsBookmarksFeedHandler.cpp&rev=1.12#285

Comment 17

[Phil Ringnalda (:philor)]

This bug has nothing to do with refreshing of Live Bookmarks, or with loading of RSS feeds, or with the cache itself misbehaving: the bug is that the autodiscovery icon in the addressbar is not displayed when a cached page (or, possibly in other circumstances, an uncached page) is opened in a new window, which is probably the result of the events that trigger its display not firing. If you're looking for cache bugs, or networking bugs, you'll probably find nothing of interest here.

Comment 18

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #17)
> the bug is that the autodiscovery icon in the addressbar is not displayed when
> a cached page (or, possibly in other circumstances, an uncached page) is opened
> in a new window

Oh, UI only issue when <link rel="alternate" type="application/rss+xml" ...> is defined in HTML.
If cached data of the RSS feed's URI has relation to this bug, "expired or not expired" is suspectable. But if so, it's hard to explain "problem when new window only".
Sorry for my misunderstandig of this bug.

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

The DOMLinkAdded event is being fired before the event handler is added.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

mozilla/browser/base/content/browser.js 	1.479.2.67 	mozilla/browser/base/content/browser.js 	1.565 

Comment 21

[Phil Ringnalda (:philor)]

*** Bug 318087 has been marked as a duplicate of this bug. ***

Comment 22

[Tanner M. Young [:tmyoung]]

Resetting QA Contact to default.