850171 - Apparent conflict with Firefox 19, Personas, and Adobe Flex programs on Mac OS

Status: RESOLVED WORKSFORME

(Firefox :: Theme, defect)

Description

[C. Laforet]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22

Steps to reproduce:

We have created an Adobe Flex program and ran it on a Mac OS (v. 10.6.8) with the latest Adobe Flash player with a theme on the browser (we are using flash version 11.6.602.171).  We run the program with no problems, switch tabs and then switch back to the program.


Actual results:

When we switch back, the UI no longer updates until an event is triggered outside the program.  This has also been found on the 'Tour de Flex' website.  You can go here: www.adobe.com/devnet-archive/flex/tourdeflex/web/#sampleId=99935;docIndex=-1;illustIndex=0 .  Try dragging the items and everything works fine.  Then change tabs (with a theme on the browser) and switch back.  Now when you try to drag, nothing happens until an external event is triggered.  If you turn off the browser theme, everything works normally.


Expected results:

Switching tabs should not affect the flash UI update regardless of the browser theme being used.

Comment 1

[Hans Peter]

Please have a look at Bug 857160
https://bugzilla.mozilla.org/show_bug.cgi?id=857160

Maybe it's the same problem. What do you think?

Comment 2

[Loic]

Hans, could you test the STR given by C. Laforet, and report if you observe the same issue.

Comment 3

[Hans Peter]

I don't know what to look for. I think we need C. Laforet to explain it better, or make another test case.

Comment 4

[Loic]

(In reply to Hans Peter from comment #3)
> I don't know what to look for. I think we need C. Laforet to explain it
> better, or make another test case.

1) Install a browser theme (known to cause issues on your machine)
2) Go to http://www.adobe.com/devnet-archive/flex/tourdeflex/web/#sampleId=99935;docIndex=-1;illustIndex=0
3) Drag and move items (blue horizontal bars)
4) Change the tab and switch back
5) Drag and move items

Comment 6

[Loic]

It's probably a regression somewhere.
Please, could you use the devtool mozregression (see http://harthur.github.com/mozregression/) to find a possible regression range.

Just create a new profile (see https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles), install a browser theme then use this profile with mozregression (--profile=/path/to/profile).

FF19 nightlies started in October 2012 (mozregression --good=2012-10-01 --profile=/path/to/profile).

Comment 7

[Hans Peter]

(In reply to Loic from comment #4)

> 1) Install a browser theme (known to cause issues on your machine)
> 2) Go to
> http://www.adobe.com/devnet-archive/flex/tourdeflex/web/#sampleId=99935;
> docIndex=-1;illustIndex=0
> 3) Drag and move items (blue horizontal bars)
> 4) Change the tab and switch back
> 5) Drag and move items

I have done all of the above, and I can't reproduce the issue.

Comment 8

[Loic]

So try with your own STR (Youtube videos).

Comment 9

[Hans Peter]

Why on earth should I do that on a bug that I can't reproduce on the version described? But I'll be happy to use mozregression on the bug I filed and I can reproduce.

And Loic please understand that I'm happy for the attention you have given the issue.

Comment 10

[Loic]

(In reply to Hans Peter from comment #9)
> Why on earth should I do that on a bug that I can't reproduce on the version
> described? But I'll be happy to use mozregression on the bug I filed and I
> can reproduce.
> 
> And Loic please understand that I'm happy for the attention you have given
> the issue.

I reopened your bug, feel free to find a regression range with your own STR. :)

Comment 11

[Paul Silaghi, QA [:pauly]]

I reproduced this on FF 20 using the STR in comment 4. I used http://www.getpersonas.com/en-US/ instead of themes.

Last good nightly: 2012-10-24
First bad nightly: 2012-10-25

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=93cc1ee94291&tochange=5c82f5a5e90d

Comment 12

[Paul Silaghi, QA [:pauly]]

It seems it is no loger reproducible on nightly 23.0a1 (2013-04-07).

Comment 13

[Paul Silaghi, QA [:pauly]]

Anthony, do you think there should be done something given that this is repro on FF 20, but not on 21b1, 22.0a2(2013-04-07), 23.0a1 (2013-04-07) ?

Comment 14

[u279076]

(In reply to Paul Silaghi [QA] from comment #13)
> Anthony, do you think there should be done something given that this is
> repro on FF 20, but not on 21b1, 22.0a2(2013-04-07), 23.0a1 (2013-04-07) ?

Can you try to narrow down the fixed range? I don't see this being a .point release driver but if we knew when it was fixed it might be uplifted as a ride-along. Otherwise we can call this WORKSFORME and let it ride to Firefox 21 (releasing in 5 weeks).

Comment 15

[Paul Silaghi, QA [:pauly]]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #14)
> Can you try to narrow down the fixed range?
Last bad nightly: 2013-01-16
First good nightly: 2013-01-17

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d8be4bc4fba8&tochange=712eca11a04e

Comment 16

[u279076]

(In reply to Paul Silaghi [QA] from comment #15)
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=d8be4bc4fba8&tochange=712eca11a04e

Thanks Paul. There is nearly 200 changesets in that pushlog. Any chance you could narrow it down further? We need to identify the specific changeset which fixed it so we can evaluate uplift risk. 

That said, we are already going out with Firefox 20.0.1 and we'd only uplift this if:
A) a low-risk patch was found that we could take as a ride along to a Firefox 20.0.2
- and -
B) a 20.0.2 was necessary for something more critical

Additonally, I think the use case here is fairly narrow given that feedback channels are pretty quiet with respect to this issue.

Finally, this bug will cease to be an issue once we release Firefox 21 on May 14. I think it's probably okay to wait until then and wontfix this for Firefox 20.

I'm open to objections though.

Comment 17

[Daniel Holbert [:dholbert]]

Resolving as WORKSFORME based on comment 12 through comment 15.