434712 - Network activity while edit bookmarks

Status: RESOLVED WONTFIX

(Firefox Graveyard :: Microsummaries, defect)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008051906 Minefield/3.0pre Firefox/2.0.0.14
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008051906 Minefield/3.0pre

When I edit a bookmark, Firefox send something data to network.

Reproducible: Always

Steps to Reproduce:
1.Right click bookmark item to open properties window.

or 

1.Open Lobrary
2.Select bookmark to show deteil pane.
Actual Results:  
Firefox send something data to network.

Expected Results:  
Do not send anything to network.

Comment 1

[Daniel Veditz [:dveditz]]

Looks like it reloads the bookmark in the background... to refresh the favicon maybe? To do something like IE where it shows bookmarks with updated content (but I don't see any indication of that)?

Not a security exploit so removing the security-sensitive state so more people can see this. Might be able to argue a privacy issue or useless/wasteful network traffic.

Comment 2

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

This is likely the request from the microsummary service that's looking for microsummaries to offer for that bookmark.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #2)
> This is likely the request from the microsummary service that's looking for
> microsummaries to offer for that bookmark.

Indeed, that's likely to be what it is.  Note that all such requests have the request header X-Moz set to "microsummary", so to confirm, look at the request with the LiveHTTPHeaders extension or a similar tool.

Comment 4

[Daniel Veditz [:dveditz]]

Yes, the initial requests have "X-Moz: microsummary" headers (but not sub-requests such as style-sheets).

Why does the microsummary service need to check each time?

Comment 5

[Steve Russell (RaiseMachine)]

Here's a little test that I done to see if I could confirm this.

I deleted the cookie exception entry for a couple of sites in my bookmarks. So from now on FF has to ask me (because I've got Keep until: set to "ask me every time") whether to accept or block any cookies from these particular sites.

I opened the Library window and single-clicked the entry for these sites. Every time I done this, the cookie dialog would appear asking me what to do with the cookie. I also got a second opinion using the LiveHTTPHeaders extension as per comment 3.

Confirming this so requesting Status be changed to NEW.

Comment 6

[Steve Russell (RaiseMachine)]

Bug reporter does not have canconfirm permission. Please could someone with that privilege please change the status as this has been confirmed. Thanks :)

Discussion here: http://forums.mozillazine.org/viewtopic.php?t=660824

Comment 7

[Steve Russell (RaiseMachine)]

Set flag to block FF3? Please excuse if not correct... :)

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

You're excused. That wasn't correct. :)

Myk/Dan/Gavin: can you confirm comment 5? That doesn't sound like it's uSummaries only ...

Comment 9

[Daniel Veditz [:dveditz]]

Microsummaries is reloading the page, reloading the page sends/sets cookies as normal. I can confirm that's what's happening but it sounds like it's on purpose so I don't think we know this is a valid confirmable bug.

It's kind of annoying, especially given how few pages have microsummaries. I guess it's a consequence of populating the bookmark properties live in the 'Library' window rather than waiting for the user to explicitly open a separate properties dialog, and if so it wouldn't be a "bug".

Myk's call, I think.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #4)
> Why does the microsummary service need to check each time?

The microsummary service checks to see if the page provides microsummaries so it can expose them to the user if available.  It checks each time because pages that didn't provide microsummaries in the past might start providing them.


(In reply to comment #8)
> Myk/Dan/Gavin: can you confirm comment 5? That doesn't sound like it's
> uSummaries only ...

It's possible the behavior described in comment 5 is due to microsummaries.

The microsummary loader is designed to not prompt the user about microsummary loads, i.e. to silently fail if there is any problem with the load that would normally cause the user to get prompted (like an HTTP authentication request).

But maybe the microsummary service is failing to silently fail when the user has specified that he would like to be asked every time about cookies.


> Myk's call, I think.

The network activity isn't a bug, it's intentional behavior.  The cookie prompt, on the other hand, is a bug, although given how uncommon it is for users to set that pref to prompt them for every cookie, I don't think it's a blocker.

Comment 11

[Michael Kraft [:morac]]

I have a problem with what Firefox is doing when editing bookmarks.  I have a bookmark that I use to kick off a line quality test for my home connection.  The specific URL is http://www.dslreports.com/qualtest?ip=x.x.x.x (ip address masked).  

I noticed that periodically the test would kick off on it's own without me opening the bookmarked page.  I finally figured out that Firefox was initiating the request in the background any time I selected the bookmark in the "Library" or by right clicking on the bookmark and selecting "properties".  Even though the "X-Moz: microsummary" header is set, thinks its a connection from the user.  

So basically trying to edit the bookmark, made Firefox connect to the web page which is definitely not desirable in cases where visiting a link does something automatically, especially since login cookies are also sent.  I know you can turn off microsummaries completely, but there should be an option to prevent a bookmark from automatically making a background connection to the page.

Comment 12

[u88484]

Confirming based off all the confirmations..not saying this is a bug or needs to be changed but at least needs clarification on what is going on.

User on mozillazine.org stated that changing 'browser.microsummary.enabled' to false does stop the network activity.

Comment 13

[walter]

'browser.microsummary.enabled' to false ist working for FF3. for FF2 it hasn't any effects.

because i found no way to search in bookmarkfields description and keywords i need to stay with FF2 (without the stars in the awesomebar).

is there a way for FF2 to avoid these connections each time i edit bookmarks ?

the fact of "silent connections" is realy a little bit shocking. i changed to mozilla-firefox a few month ago because of the good image for security and privacy.

i did much research on competitors and stored much information in bookmark-descriptions. i installed a tool now for watching the connection: every edit do connect to bookmark-url.the competitors get knowledge: this ip (mine) is working on me. great !

and because there is no possibility to search in these descriptions with FF3 i need to stay in FF2 with these connections ... 

or do you no how to search these field (and keywords, not only the tags) in FF3 ?
    

   

Comment 14

[(mostly gone) XtC4UaLL [:xtc4uall]]

(In reply to comment #10)
> > Why does the microsummary service need to check each time?
> 
> The microsummary service checks to see if the page provides microsummaries so
> it can expose them to the user if available.  It checks each time because pages 
> that didn't provide microsummaries in the past might start providing them.
> 
> The network activity isn't a bug, it's intentional behavior.

i think this "proactive" behavior is questionable. it should be rather "on-demand" and hence to be changed acting that way.

Comment 17

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

- BUGSPAM -
Wontfixing all Microsummaries bugs, since the feature has been removed from the core product and previous versions won't get further fixes for it.
If interested in supporting Microsummaries in your add-on, you're free to use our old microsummaries code and to search all previously open bugs by looking for [microsummaries-feature-removal] in the status whiteboard field.