Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 433956

Summary:

Theme engine stuck in infinite loop eating CPU

Product:

[ECD] Orion

Reporter:

Mark Macdonald <mamacdon>

Component:

Editor

Assignee:

Mark Macdonald <mamacdon>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

Version:

5.0

Target Milestone:

6.0 M2

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
theme data	none

Description Mark Macdonald

2014-05-01 17:00:00 EDT

I pulled changes recently that impacted the editor theme, and while I am in the editor my browser is now constantly updating the page stylesheet. It bogs down the editor performance.

You can tell this is happening by clicking the Pause button in the Chrome JS debugger. The execution will pause somewhere in ThemePreferences.js, because that file is running practically all the time. It doesn't completely hang the browser since some async work is involved that gives the UI a chance to breathe, but it is very slow.

There's supposed to be a terminating condition there but it is clearly not hitting it.

Comment 1 Mark Macdonald

2014-05-01 17:05:05 EDT

Created attachment 242616 [details]
theme data

This is my cached theme data, captured from localStorage. 

Note the "version": "6" identifier. I expected that would cause the theme engine to leave my cached theme data alone since it's already at the latest version.

Comment 2 Mark Macdonald

2014-05-08 17:15:41 EDT

1) Container and editor theme are versioned separately, but only the container theme's version is persisted into the pref (which is shared by both themes). If the container and editor versions differ, this can cause a ThemePreferences for the container to fight with the editor, thinking that the persisted theme pref data is stale when it really is not.

2) When a ThemePreferences reacts to a change in the theme pref (which may be caused in another tab), in addition to refreshing its page styles, it also writes the pref again, every time.

This lead to a very bad situation when multiple tabs were open, and the editor vs container theme version numbers differed. Basically, Tab A would write the latest editor theme data to the pref, and a listener would fire in Tab B for its container ThemePreferences. That ThemePreferences would see the version number didn't match its own, and write different data to the pref.

Tab A had a similar listener that runs in exactly the same fashion, starting the cycle again. It gets worse the more editor tabs you have open.

Comment 3 Mark Macdonald

2014-05-08 17:33:56 EDT

I fixed (1) by making the version ids the same for container & editor. This was sufficient to fix the CPU bug for me.

Tried to fix (2) but it seems to resurrect an issue we've seen before the past, where the theme you end up with upon loading Orion with a clean localStorage slate does not quite match the Prospecto theme (which is supposed to be the default). So I'm leaving it for now.

http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=b5b6dd4

Comment 4 Mark Macdonald

2014-05-09 18:06:50 EDT

Reopening. Somehow I've managed to get into this state again, although it's not as easy to reproduce.

Comment 5 Mark Macdonald

2014-05-09 18:09:25 EDT

(In reply to Mark Macdonald from comment #4)
> Reopening. Somehow I've managed to get into this state again, although it's
> not as easy to reproduce.

False alarm -- I was running off an old branch that didn't contain commit b5b6dd4. Marking FIXED again.