RSS feeds and tabs - drag and drop doesn't update feed listing

RESOLVED DUPLICATE of bug 266904

Status

()

RESOLVED DUPLICATE of bug 266904
14 years ago
7 years ago

People

(Reporter: marcia, Assigned: vlad)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Seen using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b)
Gecko/20050210 Firefox/1.0+

STR:

1. Have several tabs open, including http://del.icio.us/.
2. Click on the RSS feed icon on the bottom of the del.icio.us page
3. More than one feed shows, when there is only supposed to be one feed
available from that site
4. In the example I saw, some of mozillazine feeds were showing in the
del.ico.us tab even though they weren't available from that page

I have seen this behavior intermittently in my testing, and have not been able
to reproduce this consistently. Will work on trying to do so and report back,
but wanted to get a bug filed to track since I have seen it enough now in my
testing.
I think drag and drop might be the culprit here.

1. have two tabs open:

a. one containing a link to a page with RSS feeds, such as http://del.icio.us/
(this example has 1 feed, such as this current page)

b. second one with a page loaded which also containing RSS feeds, such as
http://www.mozilla.org (this example has 3 feeds).

2. look at the RSS menu in tab (b) and confirm its feeds appear fine.

3. go to tab (a) and drag the link for http://del.icio.us/ onto tab (b).

4. go to tab (b) wait for http://del.icio.us/ to finish loading.

5. look at the RSS menu in the statusbar.

results: still displays the 3 feeds for mozilla.org.

expected: should display the 1 feed for http://del.icio.us/
Hardware: Macintosh → All
workaround: reload tab (b) and its correct RSS feed will then display.
Flags: blocking-aviary1.1?
Summary: RSS feeds and tabs - inconsistent behavior → RSS feeds and tabs - drag and drop doesn't update feed listing

Updated

13 years ago
Flags: blocking-aviary1.1? → blocking1.8b4+
Assignee: bugs → vladimir

Updated

13 years ago
Whiteboard: [eta ?]
Ok, I don't think we can get this for 1.8b4, maybe even not for 1.5 at all.  The
problem here is just a continuation of the tabbrowser.xml/browser.xml pain with
favicons and previous live bookmark problems.  tabbrowser goes through great
pains to present just one WebProgressListener for the entire set of tabs, only
passing through status messages for the current tab, and passing an
onLocationChanged whenever the current tab is switched.  The problem is, when a
load happens entirely in the background, browser.js's WebProgressListener
receives no notifications.

The live bookmarks stuff hooks into the DOMLinkAdded event to populate the list
of live bookmarks.  This list is kept in an array on a property of the browser
for which the link elements appear (event.target's ownerDocument's browser). 
The list is only cleared in WebProgressListener's startDocumentLoad -- which is
never called if the load is happening in a background tab.  So if there's a
cheap way to find out when a new page is starting to load in a tab, then we can
just set livemarkLinks to null on the browser, and all would be well, but I'm
not sure how we can do that.

(The real future fix is to teach browser.js about multiple tabs, and about
handling events for multiple browser instances within a tabbrowser.)

Comment 4

13 years ago
This seems to work now. Probably fixed by our new tab drag and drop implementation.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Flags: blocking1.8b4+
Resolution: --- → WONTFIX
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Neither fixed nor wontfix, but a duplicate.

*** This bug has been marked as a duplicate of 266904 ***
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → DUPLICATE
Whiteboard: [eta ?]
You need to log in before you can comment on or make changes to this bug.