Find out why we're doing a bunch of synchronous file reading at the start of the customize mode transition

RESOLVED FIXED in Firefox 29

Status

()

Firefox
Toolbars and Customization
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: mconley, Assigned: mconley)

Tracking

(Blocks: 1 bug)

Trunk
Firefox 30
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox29 fixed, firefox30 fixed)

Details

(Whiteboard: [Australis:P-][qa-])

Attachments

(1 attachment, 1 obsolete attachment)

This seems to be pretty consistent, at least on Windows 7:

http://people.mozilla.org/~bgirard/cleopatra/#report=ca64499befcd287bb59c1c994f64abb1334ac5d4

We're doing a whole cluster of synchronous disk reads, which is almost certainly not helping us kick off the customize transition in a smooth way.

I'd like to find out what these are, and if we can stop, postpone, or preload this stuff instead.
Locally landed bug 962325, and that gave me file handles on the stuff we're reading:

We're reading obj\dist\bin\browser\chrome\en-US\locale\branding\brand.dtd, and strangely (and more frequently), obj\dist\bin\res\dtd\htmlmathml-f.ent

MathML? Wtf?
Created attachment 8375766 [details] [diff] [review]
Patch v1

It seems to be related to loading up aboutCustomizing.xhtml, which is a blank document.

If I switch from using aboutCustomizing.xhtml to aboutCustomizing.xul, the MathML loads go away. Weird.

Local CART tests say this also gives us a win, at least on Windows. I'll push this to try and get some real numbers.
Assignee: nobody → mconley
Status: NEW → ASSIGNED
Created attachment 8375768 [details] [diff] [review]
Patch v1.1

Whoops, forgot a file.
Attachment #8375766 - Attachment is obsolete: true
compare talos: http://compare-talos.mattn.ca/?oldRevs=58d6c019ae5c&newRev=05780d93126f&server=graphs.mozilla.org&submit=true

Starting to look like a win here - but I'm going to wait until the Win Xp and 10.8 talos jobs get scheduled and run before I request review.
Comment on attachment 8375768 [details] [diff] [review]
Patch v1.1

Looks like a winner, CART-wise - let's try this.
Attachment #8375768 - Flags: review?(gijskruitbosch+bugs)

Comment 7

4 years ago
sadness
Comment on attachment 8375768 [details] [diff] [review]
Patch v1.1

Review of attachment 8375768 [details] [diff] [review]:
-----------------------------------------------------------------

This is like the saddest patch I've had to review. I mean, if it works, and the icon and tab title all work, I guess we can do this. Can you file a followup bug to figure out why using HTML is so much worse here? I'd like to migrate stuff from XUL to HTML, not the other way around. :-(
Attachment #8375768 - Flags: review?(gijskruitbosch+bugs) → review+
Yeah, this blows, but I don't know how else to get rid of the loads. :/

Filed follow-up bug 973020.
Sad patch landed:

remote:   https://hg.mozilla.org/integration/fx-team/rev/11fae31f5b14
Whiteboard: [Australis:P-] → [Australis:P-][fixed-in-fx-team]

Comment 10

4 years ago
https://hg.mozilla.org/mozilla-central/rev/11fae31f5b14
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P-][fixed-in-fx-team] → [Australis:P-]
Target Milestone: --- → Firefox 30
Comment on attachment 8375768 [details] [diff] [review]
Patch v1.1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 

Australis.


User impact if declined: 

Potentially jankier customize mode transition.


Testing completed (on m-c, etc.): 

Local testing, and some baking on m-c.


Risk to taking this patch (and alternatives if risky): 

Very very low.


String or IDL/UUID changes made by this patch:

None.
Attachment #8375768 - Flags: approval-mozilla-aurora?
Attachment #8375768 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox29: --- → affected
status-firefox30: --- → fixed

Updated

4 years ago
Whiteboard: [Australis:P-] → [Australis:P-][qa-]
You need to log in before you can comment on or make changes to this bug.