en.m.wikipedia.org - Expanding sections takes a long time #24923
Comments
softvision-sergiulogigan
added
the
severity-important
softvision-sergiulogigan
changed the title
|
I can reproduce this issue.
Tested with: |
|
to note that this not happening on all pages. It seems to happen on pages which contains complex content in the sub-section (images, tables, etc.) A section has this markup. <h2
class="in-block section-heading collapsible-heading"
tabindex="0"
aria-haspopup="true"
aria-controls="content-collapsible-block-0"
>
<div
class="mw-ui-icon mw-ui-icon-mf-arrow mw-ui-icon-element indicator"
title=""
></div>
<span class="mw-headline" id="Tournament">Tournament</span
><span class="mw-editsection"
><a
href="/w/index.php?title=2019_Australian_Open&action=edit&section=1"
title="Edit section: Tournament"
data-section="1"
class="mw-ui-icon mw-ui-icon-element mw-ui-icon-minerva-edit-enabled edit-page"
>Edit</a
></span
>
</h2>
<div
class="mf-section-1 collapsible-block"
id="content-collapsible-block-0"
aria-pressed="false"
aria-expanded="false"
>
<!-- cut the content -->
</div>and (c.prototype._enable = function(e, t, s, a) {
var c,
l,
h,
m,
d,
f = this,
b = mw.config.get("wgMFCollapseSectionsByDefault");
function g() {
var t = window.location.hash;
0 === t.indexOf("#") && f.reveal(t, e);
}
(c =
e
.find("> h1,> h2,> h3,> h4,> h5,> h6,.section-heading")
.eq(0)
.prop("tagName") || "H1"),
void 0 === b && (b = !0),
(l = !b || "true" === mw.storage.get("expandSections")),
e.children(c).each(function(n) {
var c,
u = e.find(this),
p = u.find(".indicator"),
d = t + "collapsible-block-" + n;
u.next().is("div") &&
((m = u.next("div")),
(c = Boolean(m.attr("data-is-reference-section"))),
u
.addClass("collapsible-heading ")
.data("section-number", n)
.data("page", s)
.attr({
tabindex: 0,
"aria-haspopup": "true",
"aria-controls": d
})
.on("click", function(e) {
e.target.href || (e.preventDefault(), f.toggle(u));
}),
(o.rotation = l ? 180 : 0),
(h = new i(o)),
p.length ? p.replaceWith(h.$el) : h.prependTo(u),
u.data("indicator", h.$el),
m
.addClass("collapsible-block")
.eq(0)
.attr({
id: d,
"aria-pressed": "false",
"aria-expanded": "false"
}),
(function(e, t) {
t.on("keypress", function(s) {
(13 !== s.which && 32 !== s.which) || e.toggle(t);
})
.find("a")
.on("keypress mouseup", function(e) {
e.stopPropagation();
});
})(f, u),
!c && ((!a && r.isWideScreen()) || l) && f.toggle(u));
}),
(function() {
var t = mw.config.get("wgInternalRedirectTargetUrl"),
s = !!t && t.split("#")[1];
s && ((window.location.hash = s), f.reveal(s, e));
})(),
g(),
(d = e.find("a:not(.reference a)")).on("click", function() {
void 0 !== d.attr("href") &&
d.attr("href").indexOf("#") > -1 &&
g();
}),
n.getWindow().on("hashchange", function() {
g();
}),
!r.isWideScreen() && s && (u(this, e, s), p(s));
}), |
|
(c.prototype.toggle = function(e) {
var t,
s = e.is(".open-block"),
n = e.data("page"),
a = e.next();
e.toggleClass("open-block"),
e.data("indicator").remove(),
(o.rotation = s ? 0 : 180),
(t = new i(o).prependTo(e)),
e.data("indicator", t),
a
.toggleClass("open-block")
.attr({ "aria-pressed": !s, "aria-expanded": !s }),
this.eventBus.emit("section-toggled", {
expanded: s,
page: n,
isReferenceSection: Boolean(
a.attr("data-is-reference-section")
),
$heading: e
}),
r.isWideScreen() ||
(function(e, t) {
var s = e.find("span").attr("id"),
r = e.hasClass("open-block"),
n = l(t);
s &&
(r
? (n[t.title][s] = new Date().getTime())
: delete n[t.title][s],
h(n));
})(e, n);
}),
(c.prototype.reveal = function(e, t) {
var s, r;
try {
(r = (s = t.find(a(e))).parents(".collapsible-heading"))
.length ||
(r = s
.parents(".collapsible-block")
.prev(".collapsible-heading")),
r.length && !r.hasClass("open-block") && this.toggle(r),
r.length && window.scrollTo(0, s.offset().top);
} catch (e) {}
}), |
|
with Firefox Desktop and RDM and Firefox Android UA. and here a focus on opening @emilio performance issue? |
|
I don't see anything in those profiles that indicate that the process is busy, what makes you think that? Seems like it's mostly the compositor waiting for screenshots, cc @mstange. |
|
When we tap on the menu, it takes a long time for the section to expand and appears (with or without the performance tools working). |
|
Well, sure, I'm just saying that there's nothing obvious in those profiles... I also cannot reproduce this on my phone, which is really weird... |
ah no this is good to have this difference. |
|
Mine is a OnePlus 6 with Android 9 as well. |
You can see the activity in the "Web Content (2/2)" thread which is hidden by default: https://perfht.ml/2XgMZVt
Yeah, the screenshot capturing code has problems :-/ On my Moto G5, expanding the subsections on the Australian Open article takes almost 3 seconds... |
|
@mstange Thanks! In which product/componentof Mozilla bugzilla should we file a bug? |
Oh, I see. I actually see what's happening there. I'm not quite sure why I cannot repro locally, but they are calling getComputedStyle a bunch in |
|
Thanks @emilio. Let's make it a dup, and we can still come back to it if we find that was not the case. |
|
Close as duplicate of #1381071 (Mozilla) |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue at https://webcompat.com/issues/new if you are experiencing a similar problem. |
karlcow
added
the
type-bad-performance
URL: https://en.m.wikipedia.org/wiki/2019_Australian_Open
Browser / Version: Firefox Mobile 66.0
Operating System: Android 7.1.1
Tested Another Browser: No
Problem type: Something else
Description: Performance on page is extremely slow, taking multiple seconds to expand a section.
Steps to Reproduce:
Scrolling the page, rendering takes many seconds to catch up, and tapping on a section it takes seconds to expand.
Browser Configuration
Console Messages:
From webcompat.com with ❤️
The text was updated successfully, but these errors were encountered: