Opened 2 years ago

Closed 4 months ago

Last modified 4 months ago

#23111 closed defect (wontfix)

A web page is slowing down your browser.

Reported by: cypherpunks Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-usability-website
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Check https://blog.mozilla.org/blog/2017/06/01/mozilla-brings-virtual-reality-to-all-firefox-users/ e.g. with High Security Settings. It is awful. Is there anything to improve that from the browser's side?

Child Tickets

Change History (15)

comment:1 Changed 4 months ago by gk

Resolution: worksforme
Status: newclosed

Works for me in Safest mode.

comment:2 Changed 4 months ago by cypherpunks

Resolution: worksforme
Status: closedreopened

WTF?
It is fucking your CPU on Safer!

comment:3 Changed 4 months ago by gk

Resolution: worksforme
Status: reopenedclosed

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS, security settings, additional browser modifications. Please, attach a screenshot as well showing the notification bar about the slowdown.

comment:4 in reply to:  3 ; Changed 4 months ago by cypherpunks

Resolution: worksforme
Status: closedreopened

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

comment:5 in reply to:  4 ; Changed 4 months ago by gk

Status: reopenedneeds_information

Replying to cypherpunks:

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

Do you get the yellow bar as well in standard mode? If not, which of the prefs we set is causing the problem? (The ones in question are: "javascript.options.ion", "javascript.options.baselinejit", "javascript.options.native_regexp", "media.webaudio.enabled", "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".

comment:6 in reply to:  5 ; Changed 4 months ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

Do you get the yellow bar as well in standard mode?

No. But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)

If not, which of the prefs we set is causing the problem? (The ones in question are: "javascript.options.ion", "javascript.options.baselinejit", "javascript.options.native_regexp", "media.webaudio.enabled", "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".

It could be only additional load by processing scripts from aframe.io...
"media.webaudio.enabled" - seriously?

comment:7 in reply to:  6 ; Changed 4 months ago by gk

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

Do you get the yellow bar as well in standard mode?

No. But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)

If not, which of the prefs we set is causing the problem? (The ones in question are: "javascript.options.ion", "javascript.options.baselinejit", "javascript.options.native_regexp", "media.webaudio.enabled", "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".

It could be only additional load by processing scripts from aframe.io...
"media.webaudio.enabled" - seriously?

Yes, that's part of the prefs we currently set (see: #21601). But that said it would be still helpful if you could tell us which pref is causing the problem (be it by additional load or missing optimizations).

Last edited 4 months ago by gk (previous) (diff)

comment:8 in reply to:  7 ; Changed 4 months ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

Do you get the yellow bar as well in standard mode?

No. But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)

If not, which of the prefs we set is causing the problem? (The ones in question are: "javascript.options.ion", "javascript.options.baselinejit", "javascript.options.native_regexp", "media.webaudio.enabled", "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".

It could be only additional load by processing scripts from aframe.io...
"media.webaudio.enabled" - seriously?

Yes, that's part of the prefs we currently set (see: #21601).

But it does nothing. How could it be a problem?

But that said it would be still helpful if you could tell us which pref is causing the problem (be it by additional load or missing optimizations).

On Safer it sucks for about 5 min. On Standard, if you disable "javascript.options.ion", it sucks for about 30 sec. Further disabling "javascript.options.baselinejit" will give you the same result as on Safer. No surprise. But WTF with Standard?

comment:9 Changed 4 months ago by cypherpunks

Oh, wait! You say you don't see any of these issues on Linux. That's another WTF :)

comment:10 in reply to:  8 Changed 4 months ago by gk

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

Replying to gk:

Works for me, as I said, both in Safer and Safest mode. If you still see this problem, please reopen the ticket with your OS,

Windows

security settings,

Safer

additional browser modifications.

Unmodified both stable and alpha.

Please, attach a screenshot as well showing the notification bar about the slowdown.

Standard yellow bar, nothing special.

Overloads one core, loading aframe.io...

Do you get the yellow bar as well in standard mode?

No. But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)

If not, which of the prefs we set is causing the problem? (The ones in question are: "javascript.options.ion", "javascript.options.baselinejit", "javascript.options.native_regexp", "media.webaudio.enabled", "mathml.disabled", and "gfx.font_rendering.opentype_svg.enabled".

It could be only additional load by processing scripts from aframe.io...
"media.webaudio.enabled" - seriously?

Yes, that's part of the prefs we currently set (see: #21601).

But it does nothing. How could it be a problem?

But that said it would be still helpful if you could tell us which pref is causing the problem (be it by additional load or missing optimizations).

On Safer it sucks for about 5 min. On Standard, if you disable "javascript.options.ion", it sucks for about 30 sec. Further disabling "javascript.options.baselinejit" will give you the same result as on Safer. No surprise. But WTF with Standard?

What happens on "standard" without disabling anything but just using "standard"? Do you get similar results on your machine by using Firefox ESR 60 (see: https://www.mozilla.org/en-US/firefox/organizations/all/ for bundles)?

comment:11 Changed 4 months ago by cypherpunks

"But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)" similar results on virtual machine by using Firefox ESR 60.

comment:12 in reply to:  11 ; Changed 4 months ago by gk

Resolution: wontfix
Status: needs_informationclosed

Replying to cypherpunks:

"But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)" similar results on virtual machine by using Firefox ESR 60.

Thanks. This seems to be an inherent Firefox problem. I suspect the resources it needs are sufficiently high that the machine you have gets strained in "standard" mode. And that not everything is working in "safer" mode is kind of a calculated side-effect. Thus, all in all I think that's not a bug we'll be fixing.

comment:13 in reply to:  12 ; Changed 4 months ago by cypherpunks

Replying to gk:

Replying to cypherpunks:

"But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)" similar results on virtual machine by using Firefox ESR 60.

Thanks. This seems to be an inherent Firefox problem.

Yes, but Firefox is an integral part of your product, so this is your responsibility to push such bugs forward to Firefox instead of wontfixing them.
As for Safer level issue which doesn't appear on Linux, it looks more like your configuration problem than Firefox is inherently much more slower on Windows.

I suspect the resources it needs are sufficiently high that the machine you have gets strained in "standard" mode.

If some page needs something better than Core-i7 3GHz just to display, then it doesn't look like hardware problem.

And that not everything is working in "safer" mode is kind of a calculated side-effect.

No, this is a standalone problem which happens when the page is not displayed.

Thus, all in all I think that's not a bug we'll be fixing.

Sure. But that's a bug which deserves shepherding and not closing.

comment:14 in reply to:  13 Changed 4 months ago by gk

Replying to cypherpunks:

Replying to gk:

Replying to cypherpunks:

"But it still happily fucks the system when the page is visible. (Not 100% CPU, more load on 32-bit version.)" similar results on virtual machine by using Firefox ESR 60.

Thanks. This seems to be an inherent Firefox problem.

Yes, but Firefox is an integral part of your product, so this is your responsibility to push such bugs forward to Firefox instead of wontfixing them.
As for Safer level issue which doesn't appear on Linux, it looks more like your configuration problem than Firefox is inherently much more slower on Windows.

I suspect the resources it needs are sufficiently high that the machine you have gets strained in "standard" mode.

If some page needs something better than Core-i7 3GHz just to display, then it doesn't look like hardware problem.

And that not everything is working in "safer" mode is kind of a calculated side-effect.

No, this is a standalone problem which happens when the page is not displayed.

Thus, all in all I think that's not a bug we'll be fixing.

Sure. But that's a bug which deserves shepherding and not closing.

I just closed it on our side indicating that we won't fix it as part of our Tor Browser work. May I ask you to file a bug at Mozilla's bug tracker, so they get the underlying problem on their radar and provide a fix we then can backport? I think it's useful if they can get back to you directly if they have questions instead of me or us proxying the whole conversation the whole time. Thanks! (Please note the filed bug on this ticket then)

comment:15 Changed 4 months ago by cypherpunks

Unfortunately, it's not an option. BMO is lesser and lesser friendly to cypherpunks:
No anonymous submission.
"JavaScript is required to use bugzilla.mozilla.org."
BMO was broken in Tor Browser in the past.
"your email address will be accessible through public APIs and will be visible to all logged-in users of Bugzilla."
ESR support might get dropped in the near future.

I think it's useful if they can get back to you directly if they have questions instead of me or us proxying the whole conversation the whole time.

They can always do it here, because we are much more friendly to them than they to us.

Note: See TracTickets for help on using tickets.