Closed Bug 972485 Opened 11 years ago Closed 11 years ago

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

Categories

(Firefox :: Toolbars and Customization, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 30
Tracking Status
firefox29 --- fixed
firefox30 --- fixed

People

(Reporter: mconley, Assigned: mconley)

References

Details

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

Attachments

(1 file, 1 obsolete file)

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?
Attached patch Patch v1 (obsolete) (deleted) — Splinter Review
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
Attached patch Patch v1.1 (deleted) — Splinter Review
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.
Whiteboard: [Australis:P-]
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 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+
Blocks: 973020
Yeah, this blows, but I don't know how else to get rid of the loads. :/ Filed follow-up bug 973020.
Whiteboard: [Australis:P-] → [Australis:P-][fixed-in-fx-team]
Status: ASSIGNED → RESOLVED
Closed: 11 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+
Whiteboard: [Australis:P-] → [Australis:P-][qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: