870917 - Overlay scrollbars persist and flicker on Page Info dialog

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Justin Dolske [:Dolske]]

I'm not sure what irccloud.com is doing, but the scrollbars within the page remain visibile, and flicker slightly a couple of times a second. Maybe some kind of DOM manipulation that keeps triggering them? But I don't actually see anything in the page changing, I'm not sitting in a channel with a flood of messages going by.

The scrollbars also seem to easily get stuck in the "fat" on-hover version, even when I'm not hovering over them.

[irccloud seems to still be invite-only, I have some invite codes if whoever working on this needs one.]

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Can you find a regression range?

Is this Mac-only?

Comment 2

[Justin Dolske [:Dolske]]

The scrollbars don't flicker on Windows. The other issues are all specific to the new Lion-style scrollbars, so there's not much of a potential regression range to look at.

Comment 3

[Frank Yan (:fryn)]

I also see this same flickering, except when opening Page Info (cmd+i) -> Permissions on any page.

This is also Mac-only and specific to Lion-style scrollbars.

Comment 4

[Stephen A Pohl [:spohl] (OOO until 5/14)]

This may be a long-shot, but bug 865702 could be related to this. Especially bug 865702 comment 44 could explain why this bug is happening.

Comment 5

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Stephen Pohl [:spohl] from comment #4)
> This may be a long-shot, but bug 865702 could be related to this. Especially
> bug 865702 comment 44 could explain why this bug is happening.

Bug 865702 does not appear to have fixed the flickering in the page info dialog.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Here's the regression range I've found for this bug:

firefox-2013-05-02-03-09-39-mozilla-central
firefox-2013-05-03-03-09-20-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=70e0955ccc87&tochange=b35170667a2f

This almost certainly means the patch for bug 636564 is the trigger here, though maybe not the cause.

I find the scrollbar doesn't so much flicker as pulse, with a period (for turning off and on) of about .67 seconds (15 pulses every 10 seconds).  So I suppose we should be looking for a timer with that frequency.  (The I-beam cursor pulses once a second, so it's not that timer.)

Comment 7

[Stephen A Pohl [:spohl] (OOO until 5/14)]

If I had to guess I'd say that the fading in the (new) ScrollbarActivity class keeps getting reset. In ScrollbarActivity.h we have:
  static const uint32_t kScrollbarFadeBeginDelay = 450; // milliseconds
  static const uint32_t kScrollbarFadeDuration = 200; // milliseconds

which is pretty much exactly the frequency that you've observed (.67 seconds).

Comment 8

[Steven Michaud [:smichaud] (Retired)]

It'd be interesting to (say) double those numbers in a test build, and see what happens.

Comment 9

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Doubling these numbers slows down the pulsating effect, but it's still present. I've narrowed this down to our nsTreeBodyFrame class. For some reason, each time the timer expires and the scrollbars should completely disappear, we get a reflow event. In nsTreeBodyFrame::UpdateScrollbars we then call mScrollbarActivity->ActivityOccurred() which starts the timer again and makes the scrollbars reappear.

As a side note: we call mScrollbarActivity->ActivityOccurred() in nsTreeBodyFrame::InvalidateScrollbars, but I don't believe that's necessary.

Comment 10

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Attachment: Fix "Page Info" page

This patch fixes the "Page Info" page, but irccloud is still broken (pulsating scrollbars).

One problem with this patch is that the scrollbars don't appear when the list menu is first displayed. According to bug 869519 comment 1 this might actually be the desired behavior since WebKit does the same and we may choose to apply this rule to all other scrollable elements as well.

Comment 11

[Alex Keybl [:akeybl]]

Tracking assuming this will impact more web properties than just irccloud.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I've done a bit of digging around here, and have discovered that, whenever the Page Info dialog is displayed (whether or not scrollbars are displayed), nsPresShell::DidDoReflow() is called twice in a row with the same frequency that the scrollbars flicker.

That can't be right, and I suspect is at least close to whatever causes this bug.

To find this out, I drastically slowed down the frequency (by multiplying kScrollbarFadeBeginDelay and kScrollbarFadeDuration each by 10), and wrote an interpose library to print stack traces of each "interesting" call.

In my next comment I'll post the interpose library and a more detailed explanation.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

Attachment: Interpose library for debugging

This interpose library hooks calls to puts(), and prints a stack trace after each call.  So to log stack traces of "interesting" calls (from Firefox code), you need to add a call to puts() to each such call (in Firefox code).

My first test added puts() to ScrollbarActivity::ActivityOccurred().  This recorded a whole slew (8-10) of calls every time the Page Info dialog's scrollbars pulsed (or would have pulsed).  Looking up the stack traces, I noticed calls to nsPresShell::DidDoReflow().  My next test was to comment out the call to puts() in ScrollbarActivity::ActivityOccurred() and add one to nsPressShell::DidDoReflow().

Unfortunately all the C++ method names in the stack traces generated by my interpose library are mangled.  I'll try to do something about that in the future.  But in the meantime you have to run the c++filt command-line utility on each mangled line.

Stephen:  Do you want to pick this up, or should I continue my investigation?  In any case I won't get started before next week.

Comment 14

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #13)
> Stephen:  Do you want to pick this up, or should I continue my
> investigation?  In any case I won't get started before next week.

Steven, thank you very much for your help with this! I'm still quite busy fixing bug 868498 and bug 868416. I'd say if you have the bandwidth, please feel free to continue your investigation. But no pressure and I'd be happy to take this on after my two bugs are fixed. It'd be a great opportunity for me to get some real-world exposure to interpose libraries.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

I'm slowly closing in on this, but I suspect I'll need a few more days.

Along the way I noticed a closely related bug, and a way to make this bug stop happening in the Page Info window.

1) First the related bug.

a) Open a Firefox window and visit https://www.mozilla.org/en-US/ in it.  Notice that part of the page refreshes every 7-8 seconds.  Also notice that it always has a vertical scrollbar.
b) If you make the page narrow enough, the vertical scrollbar reappears (and then fades out again) every time the page is refreshed.

2) Now the Page Info workaround

If you make this page wide enough, the vertical scrollbar stops flashing in the Permissions tab.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

Oops, I updated an old (non-refreshed) page and accidentally changed the status and tracking flags.

Someone with the required permissions please reset the tracking-firefox23 and tracking-firefox24 flags to '+'.

Comment 17

[Stephen A Pohl [:spohl] (OOO until 5/14)]

fyi: the patch in bug 868416 comment 38 appears to work around the flickering in the page info dialog.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

I'm giving up on this, at least temporarily.  But I've found some things that indicate problems in cross-platform code (CSS and/or layout).

As I mentioned in comment #12, nsPresShell::DidDoReflow() is called twice in a row every time this bug happens (every time the Page Info scrollbar disappears and reappears).  This is in response to two other calls to PresShell::FrameNeedsReflow() on the nsScrollbarFrame object corresponding to the "flashing" scrollbar.  (The root frame for the calls to nsPresShell::DidDoReflow() is an nsDocElementBoxFrame object, which I assume contains the nsScrollbarFrame object.)

These calls are (indirectly) triggered by changes to the nsScrollbarFrame's "active" attribute (indicated by calls to nsScrollbarFrame::AttributeChanged()), which in turn trigger calls to CaptureChange() on the nsScrollbarFrame object (from nsFrameManager::ReResolveStyleContext()).

But the changes "captured" by CaptureChange() are very strange:  The nsScrollbarFrame's "visibility" changes from NS_STYLE_VISIBILITY_HIDDEN to NS_STYLE_VISIBILITY_COLLAPSE or vice versa (not from either of those to NS_STYLE_VISIBILITY_VISIBLE as you'd expect).  And because of code in nsStyleVisibility::CalcDifference(), a change to or from NS_STYLE_VISIBILITY_COLLAPSE always triggers a reflow.

Furthermore, during the call to nsPresShell::DidDoReflow() the nsScrollbarFrame's "active" attribute changes again (back to what it was before), which triggers a second reflow before the first call to nsPresShell::DidDoReflow() returns.  Nothing important seems to happen during the second (reentrant) call to nsPresShell::DidDoReflow().

Because the nsDocElementBoxFrame that contains the nsScrollbarFrame object was reflowed at least once, the "related bug" that I mentioned in comment #12 kicks in, and the scrollbar becomes visible again.

Comment 19

[Steven Michaud [:smichaud] (Retired)]

The "@media all and (-moz-overlay-scrollbars)" section of nativescrollbars.css contains a block that's seemingly intended to ensure that "scrollbar" objects's visibility is either "visible" or "hidden" (never "collapse"):

  scrollbar:not([active="true"]),
  scrollbar[disabled="true"] {
    visibility: hidden;
  }

But it that's its intention, it doesn't work (according to what I found in comment #18).

I've not been able to figure out why, or to come up with an alteration to the above code that stops overlay scrollbars from ever having visibility == "collapse".

My guess, from the debugging I've managed to do, is that the above code fails to override the following code from xul.css:

[collapsed="true"],
[moz-collapsed="true"] {
  visibility: collapse;
}

I've no idea why, though.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Attachment: Debugging patch (*not* a fix)

For what it's worth, here's the debugging patch I've been playing with, and which I used to draw my conclusions in comment #18 and comment #19.

Comment 21

[Steven Michaud [:smichaud] (Retired)]

David:

Robert Strong suggested you might be able to figure out what's going on here.  Please let us know if you have any ideas.

He also suggested you might have some tips and tricks for debugging style code.  All those macros make it terribly difficult for me.  For example I wasn't able to figure out exactly what code sets a scrollbar's visibility to "collapse", even though I spent several days on the problem.

Comment 22

[Steven Michaud [:smichaud] (Retired)]

Attachment: Full trace of simplest testcase (very long)

Here's a full trace, done using my interpose library and debugging patch, of the simplest testcase for this bug.  Interestingly, in this testcase the nsScrollbarFrame that (periodically) gets reflowed isn't visible.

STR:

1) Start FF on a fresh profile from Terminal.  A single window should open at about:home.

2) Open a Page Info window (using e.g. Cmd-i).

3) Maximize the Terminal window.  You should see "messages" (lines of logging) in large bunches, every 6-7 seconds.  Do whatever's necessary to isolate a single "bunch".

Comment 23

[Steven Michaud [:smichaud] (Retired)]

Attachment: Full trace of proper testcase (even longer)

Here's a full trace of a proper testcase for this bug.

STR:

1) Start FF on a fresh profile from Terminal.  Visit https://bugzilla.mozilla.org.

2) Open a Page Info window (using e.g. Cmd-i).

3) Switch to one of the tabs that has at least one scrollbar (e.g. Permissions).

4) Maximize the Terminal window.  You should see "messages" (lines of logging) in large bunches, every 6-7 seconds.  Do whatever's necessary to isolate a single "bunch".

Comment 24

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Note that in order to debug the issue described by Steven you may need to revert to a changeset prior to:
https://hg.mozilla.org/mozilla-central/rev/32e423bcd381
(see bug 868416)

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Steven Michaud from comment #21)
> He also suggested you might have some tips and tricks for debugging style
> code.  All those macros make it terribly difficult for me.  For example I
> wasn't able to figure out exactly what code sets a scrollbar's visibility to
> "collapse", even though I spent several days on the problem.

So I'll take a shot at the second question first:

https://wiki.mozilla.org/Gecko:Overview#Style_System is hopefully a useful explanation of what the style code is doing.  In order to figure out where a piece of style data is coming from for an inherited property, you might need to look at multiple style contexts if the value gets inherited down the tree -- but it doesn't sound like that's the case here.  In any case, look at the style context's mRuleNode, and then that rulenode's entire ancestor chain (via mParent) until hitting the root (mParent == nullptr).  Each of those rule nodes except for the root has an mRule; one of those rules (which should each have a useful nsIStyleRule::List method that says what's in it) should be where the value is coming from.  (The actual computation happens in nsRuleNode::WalkRuleTree and nsRuleNode::ComputeVisibilityData, but that computation is done lazily and with a good bit of sharing.)

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

So another question here:  what are the rules for when layout code is supposed to report scrollbar activity?

Comment 27

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #25)

> https://wiki.mozilla.org/Gecko:Overview#Style_System is hopefully a
> useful explanation of what the style code is doing.

Thanks for this info.  I didn't know this document existed.

In light of what it says, is the following true?

When changes are made to a XUL document, its style (and that of any
DOM nodes in it) is recomputed, and the result of this recomputation
decides whether any given Element's visibility is "visible", "hidden"
or "collapse".

Comment 28

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #26)

By "rules" do you mean CSS "rules"?

Or do you mean to ask why (precisely) an overlay scrollbar is activated every time an object beneath it is reflowed?

I'm afraid I don't (yet) know the answer to either question.

At some point I'll open a separate bug on what I call the "related problem" in comment #15.

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to Steven Michaud from comment #27)
> In light of what it says, is the following true?
> 
> When changes are made to a XUL document, its style (and that of any
> DOM nodes in it) is recomputed, and the result of this recomputation
> decides whether any given Element's visibility is "visible", "hidden"
> or "collapse".

I think so, yes, although we often optimize away some or all of the recomputation in cases where we know it's not necessary.

(In reply to Steven Michaud from comment #28)
> (In reply to comment #26)
> 
> By "rules" do you mean CSS "rules"?

Nope, just the standard English meaning of the word.

> Or do you mean to ask why (precisely) an overlay scrollbar is activated
> every time an object beneath it is reflowed?

No, I want to know what the intent is -- what behavior do we *want* overlay scrollbars to have?  It's hard to evaluate the correctness of code without know what that code is supposed to be doing.

Comment 30

[Steven Michaud [:smichaud] (Retired)]

> No, I want to know what the intent is

I don't (yet) know that, either.  Though I grant it's important to know whether the current behavior is intended or an accident (not least wrt finding out how best to change it).

But even if the current behavior *is* intended, I still think it's wrong.

Comment 31

[Steven Michaud [:smichaud] (Retired)]

I've opened bug 888027 to deal with the "related problem" from comment #15.

Comment 32

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #24)

Stephen, I still see this bug in today's mozilla-central nightly, which (presumably) contains your fix for bug 868416.

STR:

1) Visit https://bugzilla.mozilla.org.
2) Open a Page Info window (e.g. using cmd+i).
3) Click on the Permissions tab.

Comment 33

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #32)
> (In reply to comment #24)
> Stephen, I still see this bug in today's mozilla-central nightly

Hrm, same here for https://bugzilla.mozilla.org. However, where it is no longer occurring is on about:home where it used to flicker too.

STR:

1. Visit about:home
2. Open the Page Info window (e.g. using cmd+i).
3. Click on the Media tab.

So, this remains a valid bug since bug 868416 is not the 'universal' workaround that we were hoping for.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #33)

I can repro this bug (in today's mozilla-central nightly) even with your STR -- if I make the Page Info window narrow enough.

Note that (as I mentioned in comment #15) both this bug and the "related problem" (bug 888027) go away if you make the window wide enough.  I currently have no idea why.

Comment 35

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #34)
> (In reply to comment #33)
> 
> I can repro this bug (in today's mozilla-central nightly) even with your STR
> -- if I make the Page Info window narrow enough.
> 

I was just able to reproduce this as well. Interestingly enough, it only seems to occur for me when the window is at a 'medium' width, i.e. it doesn't reproduce when the window is too narrow or too wide...

Comment 36

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Although this bug was originally written against irccloud.com, most of the investigation was done on the page info dialog. Unfortunately, it turns out that those are two separate issues. The issue around irccloud.com is most likely the same as the one in bug 890897. I'm going to fix irccloud.com while working on bug 890897 and would file a new bug should it turn out to be different again. I'm going to change this bug here to be specific to the page info dialog.

Here's what's going on:
On irccloud.com we are changing attributes of the scrollbar. The important one appears to be maxpos. Whenever the contents of the chat field change, the maximum position of the scrollbar changes. This is interpreted as "scrollbar activity" and we display and fade the scrollbars. This is the same issue that Steven observed in comment 15 on mozilla.org. The tough part is that we can't simply ignore changes to maxpos, since resizing the browser window also changes maxpos and we should be displaying the scrollbars in that case (to match the behavior in Safari). It's tough to say at this point how to differentiate between these two scenarios (ideas welcome).

On the page info dialog we're dealing with a XUL tree (nsTreeBodyFrame.cpp in particular). When the page info dialog has a width between two seemingly arbitrary values something interesting is happening during reflows: The desired width of the scrollable frame first changes in a very minor way (shrinks by 2 app units) and posts a reflow callback, only to grow by the same amount after children have been reflown. We fail to detect that we grew back to the original size and don't cancel the posted reflow callback. The same original reflow also causes us to show the scrollbars and when we switch the scrollbars from visibility hidden to visible the frame must shrink back by those 2 app units. Once the posted reflow callback runs, we are back where we started: we shrink by 2 app units, post a reflow callback, grow by 2 app units etc.

I *think* that shrinking and growing during a reflow is acceptable and sometimes necessary (when children change their size during the same reflow for example). It seems logical to detect the case when we grow back to the same size we started with and cancel a posted reflow callback but I may be missing something. I'll post a patch that implements this shortly.

Comment 37

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Attachment: Patch

This patch cancels a posted reflow callback if we change the horizontal width at least twice and end up with the same width we started with.

Is this dealing with the actual problem rather than a symptom? I.e. should we cancel a reflow callback in this scenario, or should we never run into this scenario in the first place?

Comment 38

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 775072 [details] [diff] [review]
Patch

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

You're right, this scenario can happen.

Comment 39

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Sweet, thanks roc!

Pushed to inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4ed9c060c119

Comment 40

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Stephen Pohl [:spohl] from comment #36) 
> On the page info dialog we're dealing with a XUL tree (nsTreeBodyFrame.cpp
> in particular). When the page info dialog has a width between two seemingly
> arbitrary values something interesting is happening during reflows: The
> desired width of the scrollable frame first changes in a very minor way
> (shrinks by 2 app units) and posts a reflow callback, only to grow by the
> same amount after children have been reflown. We fail to detect that we grew
> back to the original size and don't cancel the posted reflow callback. The
> same original reflow also causes us to show the scrollbars and when we
> switch the scrollbars from visibility hidden to visible the frame must
> shrink back by those 2 app units. Once the posted reflow callback runs, we
> are back where we started: we shrink by 2 app units, post a reflow callback,
> grow by 2 app units etc.

Just to clarify this section, this is what's happening:
1. Scrollbars become invisible, a reflow is triggered.
2. The XUL tree reflows, detects a change in width and posts a reflow callback. It fails to cancel the reflow callback when it grows back to its original size.
3. The reflow callback updates the scrollbars, which causes us to show the scrollbars.
4. After the scrollbars fade away and become invisible we trigger a reflow, i.e. we're back at step 1.

Comment 41

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4ed9c060c119

Comment 42

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 775072 [details] [diff] [review]
Patch

This doesn't fix the underlying problems, but it's an elegant workaround :-)

I notice that it also "fixes" bug 888027 (or at least my testcase for that bug) and bug 890897.

I don't believe that overlay scrollbars should be reflowed whenever something "beneath" them is reflowed (bug 888027), or that an overlay scrollbar should ever get into a "collapsed" state (which rightly triggers a reflow -- this bug).  Both of these bugs remain unfixed.  But your workaround gets rid of a very annoying symptom, and does it in a way that (I suspect) clears up all cases of it, across all platforms (e.g. bug 888027 and bug 890897).

Comment 43

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #42)
> I notice that it also "fixes" bug 888027 (or at least my testcase for that
> bug) and bug 890897.

I did not observe this and these bugs remained unfixed for me. I just posted a patch for bug 890897, but the patch here only affects xul trees and it would have beem strange if it changed anything for those bugs.

> I don't believe that overlay scrollbars should be reflowed whenever
> something "beneath" them is reflowed (bug 888027),

Agreed. We currently show them because the nsGkAtoms::maxpos attribute changes (see bug 888027 comment 4). Unfortunately, this is also the attribute that changes when the browser window is resized. So this isn't as easy as ignoring changes to nsGkAtoms::maxpos.

> or that an overlay
> scrollbar should ever get into a "collapsed" state (which rightly triggers a
> reflow -- this bug).

I'm not very familiar with our style system, but I could see how "visibility: hidden" would be interpreted as "collapsed" state and therefore trigger this reflow.

Comment 44

[Steven Michaud [:smichaud] (Retired)]

> and bug 890897

Oops, I was wrong about this (I misread the comments there).

Stephen, are you saying that your patch for this bug also doesn't fix the irccloud problem?

Comment 45

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #44)
> Stephen, are you saying that your patch for this bug also doesn't fix the
> irccloud problem?

Right, the patch here does not fix the problem on irccloud (only the problem in the page info dialog). The page info dialog uses XUL trees, irccloud uses nsGfxScrollFrames. This bug fixes XUL trees, my patch from this morning in bug 890897 will fix nsGfxScrollFrames (i.e. irccloud etc.).

Comment 46

[Steven Michaud [:smichaud] (Retired)]

>> or that an overlay scrollbar should ever get into a "collapsed"
>> state (which rightly triggers a > reflow -- this bug).
>
> I'm not very familiar with our style system, but I could see how
> "visibility: hidden" would be interpreted as "collapsed" state and
> therefore trigger this reflow.

I don't know much about our style system, either.  But see comment #19.

Comment 47

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #46)
> I don't know much about our style system, either.  But see comment #19.

Oh, I just realized that I never replied to comment 19: I'm not sure what you've observed, but "visibility: hidden" in nativescrollbars.css does appear to work as expected. An easy way to verify this is to remove it. You will notice that the scrollbars fade out as expected, but then immediately change back to full (and permanent) visibility once the fade out completes. How this all works in detail or why the state changes to "collapsed", I wouldn't know without investigating.

Comment 48

[Steven Michaud [:smichaud] (Retired)]

  scrollbar:not([active="true"]),
  scrollbar[disabled="true"] {
    visibility: hidden;
  }

I think this means overlay scrollbars should never get into the "visibility: collapsed" state.  Do you disagree?

Comment 49

[Steven Michaud [:smichaud] (Retired)]

That they do get into the collapsed state is shown by my logs from comment #22 and comment #23.

Comment 50

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Hmm, you might have been observing the scrollbars for the scroll frame below the XUL tree in the page info dialog. Notice that when you select the entry for an icon in the list above, the actual icon will appear in the box below. This box does use nsGfxScrollFrame and when scrollbars aren't needed there, they may be in "collapsed" state. But again, without actually debugging it's hard to say for sure.

Comment 51

[Steven Michaud [:smichaud] (Retired)]

I repeat my question from comment #48 :-)

Comment 52

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Steven Michaud from comment #51)
> I repeat my question from comment #48 :-)

My understanding of this is: if scrollbars are either not set to active == "true" OR scrollbars are disabled, then set visibility to hidden. So, what could still happen is that the 'active' attribute isn't set but the scrollbar also isn't disabled. We just don't want to display it because the scrollable frame is large enough to show all the contents. In this case the scrollbars would inherit their visibility, which may be "collapsed".

As an aside, note that we only ever set active to "true", but never to "false":
http://mxr.mozilla.org/mozilla-central/source/layout/generic/ScrollbarActivity.cpp#305

Comment 53

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Well, that begs the question what scrollbar:not([active="true"]) evaluates to when the active attribute isn't set at all. So you may be right, Steven.

Comment 54

[Steven Michaud [:smichaud] (Retired)]

Thanks, Stephen.

That gives a place to start (or rather to restart) if/when we ever get back to trying to fix the underlying bug here.

Comment 55

[Stephen A Pohl [:spohl] (OOO until 5/14)]

I wonder if our assumption about inheritance was wrong. what if xul.css overrides nativescrollbars.css..? So, if we are in "collapsed" state we never set visibility to hidden because xul.css takes precedence? Just another idea to explore when/if we come back to this.

Comment 56

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Comment on attachment 775072 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 636564
User impact if declined: XUL trees may have flickering overlay scrollbars in some situations like the page info dialog.
Testing completed (on m-c, etc.): Extensive testing locally, has been on m-c for a day.
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none

Comment 57

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Requesting checkin for aurora and beta.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/92ddaae926c7
https://hg.mozilla.org/releases/mozilla-beta/rev/49c72ba550e6

Comment 59

[Ioana (away)]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:23.0) Gecko/20130505 Firefox/23.0 (20130505030916)

I tried to reproduce this issue, but it's not happening for me on Page Info -> Permissions and I don't have an irccloud account.

If someone else has access to a machine where this reproduces, please try to verify the fix on Firefox 23.

Comment 60

[Ioana (away)]

> If someone else has access to a machine where this reproduces, please try to
> verify the fix on Firefox 23.

Make sure it's a pre-07/18 build, since that's when overlay scrollbars got disabled in Firefox 23(bug 895203).

Verifications on Firefox 24 and 25 would probably be more useful.

Comment 61

[Ioana (away)]

Anthony, I removed the verifyme keyword because this bug was not reproducible on the QA machines here, so there's nothing we can do for it.

Can someone on your side try to verify this on Firefox 24?

Comment 62

[u279076]

Tracy, can you have a quick look to see if you can reproduce this and verify it's fixed in Firefox 24?

Comment 63

[Tracy Walker [:tracy]]

This is Lion only. I do not have a 10.7 machine.

Comment 64

[Stephen A Pohl [:spohl] (OOO until 5/14)]

(In reply to Tracy Walker [:tracy] from comment #63)
> This is Lion only. I do not have a 10.7 machine.

This applies to OSX 10.7 and above. Comment 33 to comment 35 have the most current STR.

Comment 65

[Tracy Walker [:tracy]]

(In reply to Stephen Pohl [:spohl] from comment #64)
> (In reply to Tracy Walker [:tracy] from comment #63)
> > This is Lion only. I do not have a 10.7 machine.
> 
> This applies to OSX 10.7 and above. Comment 33 to comment 35 have the most
> current STR.

Still no good for me, as I am on 10.6.8  

Juan, can you take a moment to do this quick verification? Thanks ahead of time.

Comment 66

[juan becerra [:juanb]]

This disappeared in a blind spot, but I am not able to reproduce this problem on a 10.9x machine with the instructions involving command-i nor with irrcloud.com

Comment 67

[Stephen A Pohl [:spohl] (OOO until 5/14)]

Odd. I can still reproduce this, but slightly differently now. Using a current nightly, I load this bug and hit Cmd-i. On the "General" tab that opens by default, there is a "Meta" list. The scrollbar there flickers. I'm unable to reproduce on the "Media" tab like I used to however.