Changes to URLs of feeds into DOM are not reflected into the feed discovery menu

VERIFIED DUPLICATE of bug 380639

Status

()

Firefox
RSS Discovery and Preview
VERIFIED DUPLICATE of bug 380639
9 years ago
9 years ago

People

(Reporter: Claudio Procida, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

Links to feeds in the feed autodiscovery menu will not update to reflect changes to URLs of alternate links made via DOM manipulation (e.g. document.getElementsByTagName('link')[0].href = 'foo.xml' // was 'bar.xml')
To update the feed autodiscovery menu a page reload is currently required, this somehow clashes with a full AJAX paradygm where the page is never reloaded entirely and you need to update the browser UI with different feeds.
Would be a really nice feature to have.

Reproducible: Always

Steps to Reproduce:
1. Load a page that contains an HTML tag like the following
<link id="foo" title="My feed" type="application/rss+xml" rel="alternate" href="foo.xml">
2. Alter the DOM via javascript by executing this statement:
document.getElementById('foo').href='bar.xml';
3. Click on the item "My feed" in the feed autodiscovery menu located in the location bar.
Actual Results:  
The link in the feed autodiscovery menu will still point to foo.xml (won't be updated)

Expected Results:  
The link in the feed autodiscovery menu should now point to bar.xml according to the updated DOM
(Reporter)

Comment 1

9 years ago
Created attachment 354954 [details] [diff] [review]
Patch for browser.js to fix missing DOMLinkRemoved events
(Reporter)

Comment 2

9 years ago
After a chat with a friend who's a XUL developer we found a quick fix for this issue, which consists into manually dispatching a DOMLinkRemoved event when a DOMNodeRemoved affecting a LINK element is caught. The relevant handler is attached only after the DOM has loaded to ignore all transitory removals

Original credit goes to Matteo "Zer0" Ferretti (zer0.kaos@gmail.com)
Please see https://developer.mozilla.org/en/Creating_a_patch for how to make a
viable patch for firefox.
(Reporter)

Comment 4

9 years ago
Created attachment 354965 [details] [diff] [review]
Patch for browser.js to fix missing DOMLinkRemoved events

Credit goes to Matteo "Zer0" Ferretti (zer0.kaos@gmail.com) who originally wrote this solution
Attachment #354954 - Attachment is obsolete: true
Attachment #354965 - Flags: review?(gavin.sharp)
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2)
> After a chat with a friend who's a XUL developer we found a quick fix for this
> issue, which consists into manually dispatching a DOMLinkRemoved event when a
> DOMNodeRemoved affecting a LINK element is caught.

Why is that needed? The core code should be firing a DOMLinkRemoved event. Listeners for mutation events like DOMNodeRemoved have a large performance penalty, so we can't afford to use this workaround.
Comment on attachment 354965 [details] [diff] [review]
Patch for browser.js to fix missing DOMLinkRemoved events

So what we could probably do is take just the DOMLinkRemoved parts of this patch (assuming they fix at least part of the bug) and then file a followup on fixing whatever core bug is causing DOMLinkRemoved not to fire.
Attachment #354965 - Flags: review?(gavin.sharp) → review-
I wonder if we could simplify the DOMLinkRemoved handler by keeping a reference to the <link> element on the feeds object, and do the lookup that way. Doing that incurs the risk of keeping documents alive longer than we normally would (we null out the feeds array on page transitions, I think), so maybe that's worth avoiding, but at the very least the code that generates feed objects for a given <link> should be factored out into a helper to avoid code duplication.
Ah, looks like this is a duplicate of bug 380639. Feel free to continue posting updates there!
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 380639
(Reporter)

Comment 10

9 years ago
(In reply to comment #7)
> (From update of attachment 354965 [details] [diff] [review])
> So what we could probably do is take just the DOMLinkRemoved parts of this
> patch (assuming they fix at least part of the bug) and then file a followup on
> fixing whatever core bug is causing DOMLinkRemoved not to fire.

Makes perfect sense to me! :)
Verified Duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.