1005566 - Hovering mouse over a link in a webpage causes SeaMonkey to send packets to that link's address.

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Mike]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.59.10 (KHTML, like Gecko) Version/5.1.9 Safari/534.59.10

Steps to reproduce:

Viewing any webpage that has links in it.


Actual results:

When the mouse passes over, or hovers over, a link, SeaMonkey 2.26 then sends packets to the URL address of that link.  (I've been monitoring the problem, using tcpdump.)


Expected results:

Nothing should happen - no packets should be sent - until the user positively clicks on the link.

Especially in this day and age, when we advise users to NOT CLICK on suspicious / unknown links ... but then SeaMonkey no longer requires a click:  SeaMonkey just goes ahead and sends packets anyway - when the mouse simply passes over a link.

I consider it a security problem, but it's silly to keep it hidden from the public; in general, I would advise users to *not* use SeaMonkey 2.26.

Firefox 29.0 is *not* showing this problem.

Comment 1

[therube]

(I don't know, understand, what I'm looking at or what is expected... & using Nirsoft's TcpLogView...)

URL: https://www.google.com/search?q=ncmain.exe

Mouse over to my hearts content & I don't see any activity.

URL: http://www.tcpdump.org/

Mouse over almost always generates some traffic.

This happens in both SeaMonkey & FF.

This occurs regardless of the "network.prefetch-next" setting.
network.http.pipelining is disabled by default.

Might all be normal, expected, & or possibly some other Prefs that are affecting what is being seen... ?

https://support.mozilla.org/en-US/kb/how-stop-firefox-automatically-making-connections
http://www.nirsoft.net/utils/tcp_log_view.html

Comment 2

[Mike]

You're attempting to test on a Windows machine.

The problem occurs on the Mac - using SeaMonkey 2.26.  The problem does not occur with SeaMonkey 2.25 (and earlier versions); and the problem does not [yet] occur with Firefox versions.

On the Mac, if you right-click on a link in a webpage, Copy the link and paste it into a TextEdit.app (an Apple text editor) window, you'll find in the TextEdit window, either a URL address (meaning, it's a "real" or "obvious" URL link) or a brief javascript string (something like "javascript ... ()" on occasion).  You'll find, usually, the same results in the Status Bar at the bottom of the SeaMonkey browser window.

In the case of the actual URL address --- I'm referring to that type of link in a webpage.

On the Mac, I'm using the Mac's built-in tcpdump command in the Terminal.app window.  I'm also double-checking the problem, by using Objective Development's *Little Snitch* program: http://www.obdev.at/products/littlesnitch/index.html

Normally with the mouse passing over / hovering over a URL link, there is no sending of packets by SeaMonkey 2.25 (nor by previous SeaMonkey versions, and the same, for Firefox).

Only with the new version 2.26, does the problem show.

No browser should send packets because the mouse merely passes over, or hovers over, a URL link.  SeaMonkey has not, and Firefox still does not.

Test - example webpage (because it provides a list of URL links): Use Yahoo's search engine and search using a topic of your choice.  You'll get a results page, usually 10 possible references to consider, in the first results page.

As you move your mouse down the list ... just move it downward in a line, passing over the list of references (ie websites' links) ... with Firefox and SeaMonkey (prior to version 2.26) ... *no* packets are sent.

With SeaMonkey 2.26, packets *are* sent every time the mouse passes over each URL link of each of those 10 references.

Comment 3

[Mike]

Adding to my recent comments at "2014-05-04 07:57:20 PDT" above ...

The problem also does not exist with iCab (an Internet browser from Germany); nor does the problem exist with Apple's Safari.

Comment 4

[Philip Chee]

(In reply to Mike from comment #2)
> You're attempting to test on a Windows machine.
> 
> The problem occurs on the Mac - using SeaMonkey 2.26.  The problem does not
> occur with SeaMonkey 2.25 (and earlier versions); and the problem does not
> [yet] occur with Firefox versions.
> 
> On the Mac, if you right-click on a link in a webpage, Copy the link and
> paste it into a TextEdit.app (an Apple text editor) window, you'll find in
> the TextEdit window, either a URL address (meaning, it's a "real" or
> "obvious" URL link) or a brief javascript string (something like "javascript
> ... ()" on occasion).  You'll find, usually, the same results in the Status
> Bar at the bottom of the SeaMonkey browser window.
> 
> In the case of the actual URL address --- I'm referring to that type of link
> in a webpage.
> 
> On the Mac, I'm using the Mac's built-in tcpdump command in the Terminal.app
> window.  I'm also double-checking the problem, by using Objective
> Development's *Little Snitch* program:
> http://www.obdev.at/products/littlesnitch/index.html
> 
> Normally with the mouse passing over / hovering over a URL link, there is no
> sending of packets by SeaMonkey 2.25 (nor by previous SeaMonkey versions,
> and the same, for Firefox).
> 
> Only with the new version 2.26, does the problem show.
> 
> No browser should send packets because the mouse merely passes over, or
> hovers over, a URL link.  SeaMonkey has not, and Firefox still does not.
> 
> Test - example webpage (because it provides a list of URL links): Use
> Yahoo's search engine and search using a topic of your choice.  You'll get a
> results page, usually 10 possible references to consider, in the first
> results page.
> 
> As you move your mouse down the list ... just move it downward in a line,
> passing over the list of references (ie websites' links) ... with Firefox
> and SeaMonkey (prior to version 2.26) ... *no* packets are sent.
> 
> With SeaMonkey 2.26, packets *are* sent every time the mouse passes over
> each URL link of each of those 10 references.

Well that's peculiar since we use the exact same Gecko engine as Firefox. SeaMonkey 2.26 corresponds to Firefox 29. Are you sure you're testing with the latest Firefox?

The first thing to check is your installed addons some of which may be "leaking". To test this go: Help -> Restart with Add-ons Disabled. If this stops the network traffic then the most likely suspect is one of your addons.

Also, could you check about:config in both SeaMonkey and Firefox for the setting for "network.http.speculative-parallel-limit"?

Third please read: http://www.ghacks.net/2013/04/27/firefox-prefetching-what-you-need-to-know/

Comment 5

[Mike]

This reply is in 2 parts.

1st part re Firefox 29.0
2nd part re SeaMonkey 2.26

Detailed info re versions of Firefox and SeaMonkey, is included.  I read your message and did all that you asked.

I do wish that you would locate a Mac, install Object Development's Little Snitch, and test with it, as well as Terminal.app's (I'm using the bash shell) tcpdump command.

------------------------------------------------------------
------------------------------------------------------------

Part 1

Firefox 29.0
------------

This first line is from a tcpdump result:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0

- - - - - - - -

[Firefox 29.0] application.ini [file contents]:

[App]
Vendor=Mozilla
Name=Firefox
Version=29.0
BuildID=20140421221237
SourceRepository=https://hg.mozilla.org/releases/mozilla-release
SourceStamp=f60bc49e6bd5
ID={ec8030f7-c20a-464f-9b0e-13a3a9e97384}

[Gecko]
MinVersion=29.0
MaxVersion=29.0

[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={ec8030f7-c20a-464f-9b0e-13a3a9e97384}&version=29.0&buildid=20140421221237

- - - - - - - -

about:config > network.http.speculative-parallel-limit default integer 6
about:config > network.prefetch-next default boolean true

Yes, Firefox 29.0's "network.prefetch-next" default boolean is set to true.  Making changes (flipping -- network.prefetch-next -- true or false) had no apparent effect in tests: Firefox 29.0 did *not* indicate the problem "bug."

I'm still testing with both: a) tcpdump, and b) Objective Development's Little Snitch program; both of which were mentioned in an earlier message.



------------------------------------------------------------
------------------------------------------------------------

Part 2

SeaMonkey 2.26 (with add-ons disabled as you requested)
--------------

This first line is from a tcpdump result:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 SeaMonkey/2.26

- - - - - - - -

[SeaMonkey 2.26] application.ini [file contents]:

[App]
Vendor=Mozilla
Name=SeaMonkey
Version=2.26
BuildID=20140428215742
SourceRepository=http://hg.mozilla.org/releases/comm-release
SourceStamp=d5dda9c6ad4e
ID={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}

[Gecko]
MinVersion=29.0
MaxVersion=29.0

[XRE]
EnableProfileMigrator=1
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}&version=2.26&buildid=20140428215742

- - - - - - - -

about:config > network.http.speculative-parallel-limit default integer 6
about:config > network.prefetch-next default boolean false

Changes (flipping -- network.prefetch-next -- true or false) had *no* effect, and the problem "bug" persists with SeaMonkey 2.26.

BTW, I also installed SeaMonkey 2.26 *fresh* without old settings and without add-ons; same results.

------------------------------------------------------------
------------------------------------------------------------

Comment 6

[Philip Chee]

OK, I'm getting kinda desperate. Go to about:config
And filter for
javascript.enabled
And turn this off *temporarily*
Do you still see network traffic on mouseover?

Comment 7

[Mike]

(In reply to Philip Chee from comment #6)
> OK, I'm getting kinda desperate. Go to about:config
> And filter for
> javascript.enabled
> And turn this off *temporarily*
> Do you still see network traffic on mouseover?

Yes.

Comment 8

[Mike]

I took a look at about:config ... searching for keyword "hover".  I found "network.seer.enable-hover-ssl" ... and I wondered, "What is 'network.seer.'?"  So I looked that up and found:

http://forums.mozillazine.org/viewtopic.php?f=23&p=13514075

 ... wherein users have trouble quitting Firefox 29.0

Though I have *not* had trouble quitting SeaMonkey 2.26, I guessed that turning OFF "network.seer.enabled" ... might be a worthwhile test (ie network related), so I flipped that switch to:

network.seer.enabled  user set  boolean  false

 ... and commenced to retest for the "bug."

That setting does appear to be related to the "bug" --- network traffic on mouseover, stopped.

Comment 9

[Mike]

I double-checked SeaMonkey 2.25 and found that its "out-of-the-box" setting for "network.seer.enabled" is:

network.seer.enabled  default  boolean  false

The "out-of-the-box" SeaMonkey 2.26 setting for "network.seer.enabled" is:

network.seer.enabled  default  boolean  true

That difference somehow equates to the "bug" (re 1005566, this buzilla page) appearing in SeaMonkey 2.26

Comment 10

[Mike]

This sheds more light:

http://www.ghacks.net/2014/05/11/seer-disable-firefox/

EXCERPTS:

"Mozilla enabled Seer in Firefox 29 and all newer versions initially, but had to disable it again after a bug was discovered that caused slow downs for some users of the browser on shut down."

"According to Mozilla, Seer is a major component of Necko Predictive Network Actions. Necko has been designed to 'improve page load time by performing overhead for connections before the connections are actually needed'."

Well, no thanks.

Comment 11

[Philip Chee]

Great Balls of Fire. Thanks for tracking this down Mike!

http://www.mozilla.org/en-US/firefox/29.0.1/releasenotes/#note-785590
29.0.1 - Seer disabled by default (1005958)

Bug 1005958 - Disable seer until new backend is rewritten
https://bugzilla.mozilla.org/show_bug.cgi?id=1005958
https://hg.mozilla.org/releases/mozilla-release/rev/bebd4af02d88

Unlike Firefox we didn't push out a 2.26.1 so we never picked up this change.

Comment 12

[Jez]

Seer sends packets to URLs not clicked on?  I vote to have it disabled by default in SeaMonkey (even once they re-enabled it again in Firefox).

Comment 13

[Philip Chee]

(In reply to Jeremy Morton from comment #12)
> Seer sends packets to URLs not clicked on?  I vote to have it disabled by
> default in SeaMonkey (even once they re-enabled it again in Firefox).

Whip up a one liner patch and set IanN as the reviewer.

Comment 14

[Edmund Wong (:ewong)]

Attachment: Disable seer by default. (v1)

Comment 15

[Ian Neal]

Comment on attachment 8426892 [details] [diff] [review]
Disable seer by default. (v1)

[Triage Comment]
r/a=me

Comment 16

[Edmund Wong (:ewong)]

Pushed to comm-aurora:
https://hg.mozilla.org/releases/comm-aurora/rev/144a6741d457

Pushed to comm-beta:
https://hg.mozilla.org/releases/comm-beta/rev/6f10e1563e16

Pushed to comm-central:
https://hg.mozilla.org/comm-central/rev/7826852a36b5

Comment 17

[Philip Chee]

q.v. Bug 1016622: Renaming mozilla::network::Seer to mozilla::network Predictor

>  // enables the predictive service
> -pref("network.seer.enabled", false);
> -pref("network.seer.enable-hover-on-ssl", false);
> -pref("network.seer.page-degradation.day", 0);
> -pref("network.seer.page-degradation.week", 5);
> -pref("network.seer.page-degradation.month", 10);
> -pref("network.seer.page-degradation.year", 25);
> -pref("network.seer.page-degradation.max", 50);
> -pref("network.seer.subresource-degradation.day", 1);
> -pref("network.seer.subresource-degradation.week", 10);
> -pref("network.seer.subresource-degradation.month", 25);
> -pref("network.seer.subresource-degradation.year", 50);
> -pref("network.seer.subresource-degradation.max", 100);
> -pref("network.seer.preconnect-min-confidence", 90);
> -pref("network.seer.preresolve-min-confidence", 60);
> -pref("network.seer.redirect-likely-confidence", 75);
> -pref("network.seer.max-queue-size", 50);
> -pref("network.seer.max-db-size", 157286400); // bytes
> -pref("network.seer.preserve", 80); // percentage of seer data to keep when cleaning up
> +pref("network.predictor.enabled", false);
> +pref("network.predictor.enable-hover-on-ssl", false);
> +pref("network.predictor.page-degradation.day", 0);
> +pref("network.predictor.page-degradation.week", 5);
> +pref("network.predictor.page-degradation.month", 10);
> +pref("network.predictor.page-degradation.year", 25);
> +pref("network.predictor.page-degradation.max", 50);
> +pref("network.predictor.subresource-degradation.day", 1);
> +pref("network.predictor.subresource-degradation.week", 10);
> +pref("network.predictor.subresource-degradation.month", 25);
> +pref("network.predictor.subresource-degradation.year", 50);
> +pref("network.predictor.subresource-degradation.max", 100);
> +pref("network.predictor.preconnect-min-confidence", 90);
> +pref("network.predictor.preresolve-min-confidence", 60);
> +pref("network.predictor.redirect-likely-confidence", 75);
> +pref("network.predictor.max-queue-size", 50);
> +pref("network.predictor.max-db-size", 157286400); // bytes
> +pref("network.predictor.preserve", 80); // percentage of predictor data to keep when cleaning up

so network.seer.enabled -> network.predictor.enabled

Comment 18

[Justin Wood (:Callek)]

(In reply to Philip Chee from comment #17)
> q.v. Bug 1016622: Renaming mozilla::network::Seer to mozilla::network
> Predictor
> 
> so network.seer.enabled -> network.predictor.enabled

Can you get a bug on file for that, its currently in aurora, so if we need this pref switch there, I want to do so before the first 32-based beta!


That said *this* bugs patch landed on comm-release in prep for SeaMonkey 2.26.1

$ hg tip
changeset:   20188:4d8e84d21689
branch:      SEA_2_26_1_RELBRANCH
tag:         tip
user:        Edmund Wong <[e-mail]>
date:        Tue May 27 10:16:23 2014 +0800
summary:     Bug 1005566 - Hovering mouse over a link causes SeaMonkey to send packets to the link's address. r+a=IanN on a CLOSED TREE

Comment 19

[Edmund Wong (:ewong)]

(In reply to Justin Wood (:Callek) from comment #18)
> (In reply to Philip Chee from comment #17)
> > q.v. Bug 1016622: Renaming mozilla::network::Seer to mozilla::network
> > Predictor
> > 
> > so network.seer.enabled -> network.predictor.enabled
> 
> Can you get a bug on file for that, its currently in aurora, so if we need
> this pref switch there, I want to do so before the first 32-based beta!
> 

This is bug 1021370.

Comment 20

[Philip Chee]

(In reply to Edmund Wong (:ewong) from comment #19)
> (In reply to Justin Wood (:Callek) from comment #18)

> so network.seer.enabled -> network.predictor.enabled

> Can you get a bug on file for that, its currently in aurora, so if we need
> this pref switch there, I want to do so before the first 32-based beta!
> 
> This is bug 1021370.

As ewong says bug 1021370