Opened 4 years ago

Last modified 6 weeks ago

#10840 new defect (bug)

Plugin upgrade sometimes shows a scrollbar

Reported by: xibe Owned by:
Priority: low Milestone: 3.6
Component: Plugins Version: 2.8.4
Severity: normal Keywords: ui-focus has-patch needs-testing
Cc: kovshenin

Description

Please see attached screenshot, made in Safari 4.0.3 on OS X.

The iframe only contains the "Plugin reactivated successfully" line.

Increasing the window's height or width does not make it disappear, or even evolve.

Attachments (2)

wp-update-iframe.png (51.6 KB) - added by xibe 4 years ago.
As seen in the wild.
10840.diff (285 bytes) - added by kovshenin 4 months ago.

Download all attachments as: .zip

Change History (16)

xibe4 years ago

As seen in the wild.

comment:1   dd324 years ago

Yes, An iframe is used for that single line of text.

The reasoning is, That the status of the re-activation can only be known on a new page load, and/or if there is a Fatal PHP error. Loading it in an iframe allows for the status to be shown on the page, and if a error occurs, for the plugin not to be activated causing the WordPress install from being inaccessible.

As for the scrollbars, I think they're supposed to be hidden, Or at least, they're not visible in most browsers i've tested with..

It nearly looks like the inner content has a higher min-height than the height of the iframe..

  • Component changed from Upgrade/Install to UI
  • Milestone changed from 2.8.5 to 2.9
  • Summary changed from Plugin upgrade sometimes shows an iframe to Plugin upgrade sometimes shows a scrollbar

comment:3   ryan3 years ago

  • Milestone changed from 2.9 to Future Release
  • Keywords needs-patch added

They are visible in Chrome und Safari, the issue is html, body { height: 100% } from global.css.

Related: #12828, [16937]

  • Component changed from UI to Plugins
  • Keywords ui-focus added

comment:7 follow-up: ↓ 8   helen4 months ago

Still a thing?

comment:8 in reply to: ↑ 7   sabreuse4 months ago

Replying to helen:

Still a thing?

Now that you mention it, I'm not sure -- I haven't seen it any time lately, but that how testing a negative on a "sometimes" goes...

Initial reporter here. Cannot test again, as I do not have access to an OS X machine anymore.

Yes it's still a thing. I just reproduced this with latest trunk, Safari 6.0.2 and latest Chrome on OS X 10.8.2. Although it's less ugly since the scroll bars are hidden unless you scroll: http://cl.ly/image/0R0n3q322C0s

To reproduce this you need to update a plugin that is currently active.

  • Cc kovshenin added
  • Keywords has-patch needs-testing added; needs-patch removed

Looks like the paragraph top margin is overflowing the body element, causing that extra margin from the top. 10840.diff adds a 1px padding-top to the body in the iframe to prevent that. Tested in Chrome and Safari under OS X, would appreciate some Windows testing too.

Also note that we use the same iframe code in bulk upgrades as well as theme upgrades. See iframe_header and iframe_footer in wp-admin/includes/template.php for more info.

  • Milestone changed from Future Release to 3.6

The iframe is set to a height of 170px and the p tag has a margin: 1em 0; causing the p of the iframe to exceed the height of the iframe it sits in. The overflow has been set to hidden, but it still generates the scroll bar because the p tag is taller than the iframe.

The p {margin: 1em 0;} is a global style.

I've got a fix on my local machine to line 81 of update.php

iframe_header( ('Plugin Reactivation'), true );

if ( isset($_GETsuccess?) )

echo '<p style="margin:0;">' . ('Plugin reactivated successfully.') . '</p>';

Finally seen it in the wild again. Capture with Chrome Version 26.0.1410.43 m: http://i.imgur.com/gIYot5A.png

Yeah, beta 1, I know...

Note: See TracTickets for help on using tickets.