Bugzilla – Full Text Bug Listing
| Summary: | [settings] user profile page is slow and synchronous, delays opening another category | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mamacdon |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=387306 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
(In reply to comment #0) > It seems that the category selection style is not changed until after the > category page is populated. This means there might be some deferreds, etc. > getting preference values, population and building of the UI, etc. before > the user ever gets feedback that their click on a category happened. It can > be a 2 or more second delay in some cases. > > We should update the category selection style before processing the page > contents so the user knows something is happening... I was wrong about this. The selection is updated immediately in most cases. The problem is specific to the user profile page. It seems to have some synchronous/blocking work happening, so that you can't switch to another category until it is fully populated. So if I'm browsing each category to see what can be changed, clicking from most categories is fine, but once I click user profile, my click on any other category is delayed by several seconds. Renaming bug to reflect the problem. (In reply to comment #1) > I was wrong about this. The selection is updated immediately in most cases. > The problem is specific to the user profile page. It seems to have some > synchronous/blocking work happening, so that you can't switch to another > category until it is fully populated. > > So if I'm browsing each category to see what can be changed, clicking from > most categories is fine, but once I click user profile, my click on any > other category is delayed by several seconds. > > Renaming bug to reflect the problem. Compounding this problem is the fact that rendering the 'User Profile' section requires loading userservicePlugin.html, which is unoptimized and pulls in all of dojo. This adds up to about 35 HTTP requests and 260KB before you can interact with the page. So in addition to making the category rendering non-blocking, we should convert userservicePlugin to AMD, remove its dojo dependencies, and add it to the build. (In reply to comment #2) > So in addition to making the category rendering non-blocking, we should > convert userservicePlugin to AMD, remove its dojo dependencies, and add it > to the build. I did this in these commits: [1] http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=e834a099143e4d93417ef8f4700d08d275675096 [2] http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a0d6e5fd2409166119f4a100e3e2afbbeee805f5 [3] http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=851d2ad928600f053da3a127cd9dc58215094330 It turns out however, that userservicePlugin is not the only culprit: there's also /mixlogin/manageopenids which causes a chain of ~27 requests for dojo files. This is harder to speed up, as the HTML+JS is generated on the server-side. Hmm... (In reply to comment #3) > It turns out however, that userservicePlugin is not the only culprit: > there's also /mixlogin/manageopenids which causes a chain of ~27 requests > for dojo files. This is harder to speed up, as the HTML+JS is generated on > the server-side. Hmm... Ok, Bug 387306 is fixed, so the number of requests should be much lower. All that remains to be fixed is the synchronous rendering (comment 1). Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |