Closed Bug 1548449 Opened 5 years ago Closed 5 years ago

6.62 - 52.62% raptor-tp6-bing-firefox / raptor-tp6-bing-firefox fcp / raptor-tp6-bing-firefox loadtime linux64-shippable, linux64-shippable-qr, osx-10-10-shippable, (Wed May 1 2019)

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Version:
65 Branch
Platform:
Unspecified
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla68
Tracking Flags:
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox68 --- fixed

People

(Reporter: aiakab, Assigned: emilio)

References

(Regression)

Details

(Keywords: perf, perf-alert, regression)

Attachments

(1 file)

Bug 1548449 - Don't render stuff in plaintext documents without a viewport. r=bzbarsky
47 bytes, text/x-phabricator-request
Details | Review

Raptor has detected a Firefox performance regression from push:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5f58e2f5d1f75f42edea41b1015a6037fe7764c3&tochange=5df5f0db2284956f3afe587cc931d471051d8700

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

53% raptor-tp6-bing-firefox loadtime osx-10-10-shippable opt 95.25 -> 145.38
50% raptor-tp6-bing-firefox loadtime windows10-64-shippable opt 55.96 -> 83.92
49% raptor-tp6-bing-firefox loadtime windows10-64-shippable-qr opt 54.75 -> 81.75
47% raptor-tp6-bing-firefox fcp osx-10-10-shippable opt 103.25 -> 152.17
43% raptor-tp6-bing-firefox loadtime windows7-32-shippable opt 57.08 -> 81.83
37% raptor-tp6-bing-firefox osx-10-10-shippable opt 88.73 -> 121.25
27% raptor-tp6-bing-firefox fcp windows10-64-shippable opt 72.90 -> 92.25
25% raptor-tp6-bing-firefox windows10-64-shippable opt 57.40 -> 71.98
25% raptor-tp6-bing-firefox loadtime linux64-shippable-qr opt 63.38 -> 79.08
23% raptor-tp6-bing-firefox windows10-64-shippable-qr opt 57.43 -> 70.53
22% raptor-tp6-bing-firefox loadtime linux64-shippable opt 65.92 -> 80.25
19% raptor-tp6-bing-firefox fcp windows10-64-shippable-qr opt 74.77 -> 89.25
7% raptor-tp6-bing-firefox linux64-shippable-qr opt 66.23 -> 70.61

You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=20739

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a Treeherder page showing the Raptor jobs in a pushlog format.

To learn more about the regressing test(s) or reproducing them, please see: https://wiki.mozilla.org/Performance_sheriffing/Raptor

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations: https://wiki.mozilla.org/Performance_sheriffing/Talos/RegressionBugsHandling

Component: Bugzilla-ETL → CSS Parsing and Computation
Flags: needinfo?(emilio)
OS: Unspecified → Linux
Product: Testing → Core
Regressed by: 1514655
Target Milestone: --- → mozilla68

So this is really wild, since this change should only affect plaintext docs.

Will take a look, but chances are that the Bing test is somehow being loaded as plaintext or such? Otherwise this doesn't make any sense at all.

(rr) p DumpJSStack()
0 Element.prototype.appendChild(n = [object HTMLObjectElement]) ["https://www.bing.com/search?q=barack+obama":11:9345]
    this = [object HTMLBodyElement]
1 kt(n = [object Object], t = [function]) ["https://www.bing.com/rms/BingCore.Bundle/cj,nj/3e6a7d75/9a358300.js?bu=rms+answers+Shared+BingCore%24ClientInstV2%24DuplicateXlsDefaultConfig*BingCore%24ClientInstV2%24SharedLocalStorageConfigDefault*BingCore%24shared*BingCore%24env.override*Empty*BingCore%24event.custom.fix*BingCore%24event.native*BingCore%24onHTML*BingCore%24dom*BingCore%24cookies*BingCore%24rmsajax*BingCore%24ClientInstV2%24LogUploadCapFeatureDisabled*BingCore%24ClientInstV2%24ClientInstConfigSeparateOfflineQueue*BingCore%24clientinst*BingCore%24replay*BingCore%24Animation*BingCore%24fadeAnimation*BingCore%24framework":3:5253]
    this = [object Window]
2 tt([object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object], [object Object]) ["https://www.bing.com/rms/BingCore.Bundle/cj,nj/3e6a7d75/9a358300.js?bu=rms+answers+Shared+BingCore%24ClientInstV2%24DuplicateXlsDefaultConfig*BingCore%24ClientInstV2%24SharedLocalStorageConfigDefault*BingCore%24shared*BingCore%24env.override*Empty*BingCore%24event.custom.fix*BingCore%24event.native*BingCore%24onHTML*BingCore%24dom*BingCore%24cookies*BingCore%24rmsajax*BingCore%24ClientInstV2%24LogUploadCapFeatureDisabled*BingCore%24ClientInstV2%24ClientInstConfigSeparateOfflineQueue*BingCore%24clientinst*BingCore%24replay*BingCore%24Animation*BingCore%24fadeAnimation*BingCore%24framework":3:4794]
    this = [object Window]
3 l() ["https://www.bing.com/rms/BingCore.Bundle/cj,nj/3e6a7d75/9a358300.js?bu=rms+answers+Shared+BingCore%24ClientInstV2%24DuplicateXlsDefaultConfig*BingCore%24ClientInstV2%24SharedLocalStorageConfigDefault*BingCore%24sha$8 = void

I have no idea why they're loading scripts via <html:object> :(

So if you go to https://www.bing.com/search?q=barack+obama in Firefox, you get 16 <object width=0 height=0> with a bunch of scripts.

If you do the same in Chromium, or you spoof the user agent, you don't. Adam, do you know if we have a partner list with Microsoft? Can you ask them why are they doing this and CC me (I don't think I'm on the list)? I'm really curious about why they need to do this. I'll land a fix to revert to our previous behavior, but this is all a bit silly.

Flags: needinfo?(emilio) → needinfo?(astevenson)

I'm still wondering why is bing.com doing this but oh well. This should address
the regression and probably even improve it.

I don't think these documents are observable from content (at least I haven't
found how) so this should be safe. Let me know if you want me to just wrap the
whole stylesheet in an @media (width > 0) and (height > 0) rule or such.

Assignee: nobody → emilio

Ah, I can join the mozilla-microsoft-discuss group.

Flags: needinfo?(astevenson)

I'm still wondering why is bing.com doing this but oh well.

This sounds kinda similar to the situation described in bug 1172205 (bug 1172205 comment 28 is where it's worth starting reading) where people were using <object> and browser-sniffing to do prefetching in Firefox because of limitations (real or perceived) in our <link rel="prefetch"> implementation. I wonder if that's what's going on here.

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/49a573cb12db
Don't render stuff in plaintext documents without a viewport. r=bzbarsky

https://hg.mozilla.org/mozilla-central/rev/49a573cb12db

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox68: affected → fixed
Resolution: --- → FIXED
Blocks: 1534654

this has fixed part of the regressed tests but introduced a new regression:

== Change summary for alert #20790 (as of Fri, 03 May 2019 08:43:53 GMT) ==

Regressions:

11% raptor-tp6-bing-firefox linux64-shippable opt 69.44 -> 77.35

Improvements:

34% raptor-tp6-bing-firefox loadtime windows10-64-shippable opt 83.42 -> 54.67
33% raptor-tp6-bing-firefox loadtime osx-10-10-shippable opt 145.96 -> 97.88
32% raptor-tp6-bing-firefox loadtime windows10-64-shippable-qr opt 83.71 -> 56.75
30% raptor-tp6m-bing-restaurants-geckoview loadtime android-hw-p2-8-0-android-aarch64 opt 241.54 -> 169.75
30% raptor-tp6-reddit-firefox loadtime windows10-64-shippable opt 3,477.56 -> 2,447.42
30% raptor-tp6-bing-firefox loadtime windows7-32-shippable opt 82.46 -> 58.08
29% raptor-tp6m-bing-restaurants-geckoview fcp android-hw-p2-8-0-android-aarch64 opt 244.33 -> 173.33
22% raptor-tp6-bing-firefox fcp windows10-64-shippable opt 93.08 -> 72.50
22% raptor-tp6-bing-firefox windows10-64-shippable opt 71.96 -> 56.21
22% raptor-tp6-bing-firefox osx-10-10-shippable opt 122.29 -> 95.76
20% raptor-tp6m-bing-restaurants-geckoview android-hw-p2-8-0-android-aarch64 opt 192.03 -> 153.20
20% raptor-tp6-bing-firefox windows10-64-shippable-qr opt 72.37 -> 58.20
17% raptor-tp6-bing-firefox fcp windows10-64-shippable-qr opt 90.92 -> 75.62
17% raptor-tp6-bing-firefox windows7-32-shippable opt 71.39 -> 59.45
16% raptor-tp6-bing-firefox fcp windows7-32-shippable opt 90.69 -> 76.08
15% raptor-tp6m-bing-geckoview loadtime android-hw-p2-8-0-android-aarch64 opt 132.04 -> 112.25
11% raptor-tp6-bing-firefox loadtime linux64-shippable-qr opt 78.54 -> 70.04

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=20790

Status: RESOLVED → REOPENED
Flags: needinfo?(emilio)
Resolution: FIXED → ---

It doesn't really make much sense that for the same build, and due to this change (which is not a graphics change), the linux64-shippable-qr platform improved but linux64-shippable regressed. I'm mildly curious about it, but given it's a progression everywhere else I don't think it's worth spending a whole lot of time investigating it. Bebe, wdyt about:

  • Closing this bug.
  • Opening a new one for the linux64 regression mentioned in comment 12?
  • I'll try to take a look at that one as time permits (though probably won't be my thing on the top of my list atm).

Thanks a lot for your work :)

status-firefox68: affected → fixed
Flags: needinfo?(emilio) → needinfo?(fstrugariu)

Err, sorry, mid-aired. I'm on the fence on whether considering 68 as affected is right given comment 12 fwiw :)

status-firefox68: fixed → affected
Regressed by: 1549934

Opened Bug 1549934

Status: REOPENED → RESOLVED
Closed: 5 years ago → 5 years ago
Flags: needinfo?(fstrugariu)
Resolution: --- → FIXED
status-firefox67: ? → unaffected
status-firefox68: affected → fixed
No longer regressed by: 1549934
Regressions: 1549934
Status: RESOLVED → VERIFIED
Keywords: perf-alert
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: