Upcoming on Bugzilla: reorganized & redesigned bug page

[Kohei Yoshino]

Hello,


As you know, bugzilla.mozilla.org has evolved to 
meet the needs of various projects, and the current bug detail page seems cluttered 
with so many fields. Making changes to a familiar UI may confuse some of you, but we 
feel like it’s time to get it improved for a more streamlined workflow. Here’s a 
brief summary of our plan:


Phase 1: Reorganized bug fields— The bug fields will soon be reorganized 
to place similar fields in 
related groups. For example, the Dependencies, Regressions, URL and See Also fields will 
move to the new References section. See this screenshot 
for how the new bug 
detail page will look like.


Phase 2: Redesigned bug page— We’ll be introducing a 2-column layout 
to make it easier to have 
a look at both bug fields and comments at the same time. The new design will also be 
optimized for mobile, so you can join a conversation comfortably on your phone!


Phase 3: Further UX enhancements— There are still many more things to do: 
simplifying the timeline, making it easier to edit bug ID and other complicated 
fields, and ultimately implementing real-time updates. Bugzilla will be pretty 
modernized at this point.


So don’t be surprised to one day see something different on your bug! Aside from regular 
BMO change logs being posted on the tools-bmo list 
, we’ll keep you posted on this 
dev-platform list with any major change that may affect you. Wanna chat? Join the #bmo 
channel on Mozilla Slack.


Thanks!


Kohei, for the Bugzilla team

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

New Custom Search UI now available on Bugzilla

[Kohei Yoshino]

Hi there,


We have enhanced search features on Bugzilla over the past months, because we 
know people search a lot. I want to let you know some of our goodies recently 
added to make your life easier.

 * New Custom Search UIon the Advanced Search page 
: It was previously 
hard to build complex queries because of the poorly designed UI. Today we have 
shipped a completely new UI that allows you to add rows/groups, move them with a 
drag-and-drop, and remove ones if necessary.

 * Aliases for status & tracking flags: Each Firefox release has status and 
tracking flags like “status-firefox67” or “tracking-firefox68” but sometimes you 
may just want to find bugs by a specific channel. You can now use convenient 
aliases like “status-firefox-release” or “tracking-firefox-beta” so you don’t have 
to update your search queries every 7 weeks or so.

 * Merge date pronouns: You can now use Firefox merge date pronouns, including 
“%LAST_MERGE_DATE%” and “%LAST_RELEASE_DATE%”, for date fields.

 * Search in bug description: Searching in comments can be slow, but if you 
know what you’re looking for is in the bug’s description (comment 0), you can 
get results faster by ticking the “Description (initial comment) only” checkbox 
on the Advanced Search page.

So what’s next? We are currently working on an overhaul of the search results page 
, that will be richer and 
faster than the current plain table presentation. It should be coming in the next 
month or two.


Happy searching!


Kohei, for the Bugzilla team

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Kohei Yoshino]

An update on the bug type and regression fields:

Because of Firefox 66 and the subsequent 66.0.1 pwn2own chemspill, we decided 
to delay the deployment of the change. We are now ready to deploy the new bug 
type and regressions/regressed-by fields to production Bugzilla later this week.

A one-time bug type auto migration will follow this weekend. It will be done 
with a component-based migration script [1] as well as the bugbug machine 
learning tool [2]. Marco tested bugbug with several bugs on the staging server 
last weekend and the results look good overall. The current instance can be 
seen on: https://bugzilla.allizom.org/

It should be noted that bugbug only classifies bugs as defect or enhancement 
over the last 2 years, because the accuracy of the detection between 
enhancement and task is not perfect. So triage owners and/or assignees will 
have to manually change the type of some existing bugs from enhancement to task 
once the migration is complete.

We’ll keep you posted.
-Kohei

[1] https://github.com/mozilla-bteam/bmo/pull/1106/files
[2] https://github.com/mozilla/bugbug


On 2019-03-12 6:55 a.m., Sylvestre Ledru wrote:

Bugzilla is one of the key tools used for the development of Firefox since the 
Netscape era. Even though this tool is serving us well, after interviewing a 
bunch of people at every level inside the company, we realized that we need to 
go the extra step.


Therefore, we decided to focus on improving Bugzilla itself but also, as a next 
step, improve the workflows we have on bugs.


To start with, we are coming with a set of three major changes to make our life 
better and easier.


1) Enforcing the usage of the priority field


As described in this schema 
,
 we are now asking triage owners to set the priority field according to the priority 
definition 
. The main 
goal is to make sure that every bug has been looked at and a priority has been set in 
accordance with the priority definitions.

A bot will automatically needinfo the triage owner (or a member of the team if 
it uses a round robin triage method).

We have been experimenting with this for several components and the results 
look great!


2) Bug type - new field

Firefox development requires a bug for every change in the Firefox code base. 
It doesn’t matter if this is used to fix a defect in the product, to implement 
a new feature or to refactor some code.


For years, we have been using bugzilla keywords to classify them. However, as 
they are not mandatory, the metadata can be missing, unmaintained, or 
inconsistent.


With this change, we are going to extend Bugzilla to add a new field with three 
new values:

  *

Defect - an issue in one of our products

  *

Enhancement - a new feature or an improvement

  *

Task - a developer task. For example: refactor code foo.


Since we don’t want to increase the confusion for new users, the default value will 
be defectand, to the best of our ability, existing bugs will be moved 
under one of these 
categories.


With this information, we will be able to more precisely measure the quality of 
our products, as we will not mix defects together with feature-related work.


We have a development instance of Bugzilla 
where the changes can be evaluated, we are 
planning to go live in the new few weeks.


More information https://bugzilla.mozilla.org/1522340


3) Adding a new field called “Regressed by”

Currently, we misuse the blocks/depends fields to mark bugs causing 
regressions. However, they can be confusing and aren’t used consistently by 
developers. Moreover, since we are using bugs for defects, enhancements or 
tasks, it can be very hard to pinpoint the changes which introduced a 
regression.

Being able to pinpoint changes which introduced regressions will make it easier 
to build tools to help with assessing the riskiness of changes.


Therefore, we will add a new field in bugzilla which will clearly identify 
which bug caused a regression.

More:

http://bugzilla.mozilla.org/1461492


Last but not least, nothing is written in stone and we have other improvements 
(bug workflow, improved search, regression field, etc) coming. Sylvestre

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Kohei Yoshino]

Due to unexpected circumstances, we couldn’t deploy and migrate the bug type 
field this week. Will try again next week as soon as on Monday.

Thanks,
-Kohei


On 2019-03-26 8:05 p.m., Kohei Yoshino wrote:

An update on the bug type and regression fields:

Because of Firefox 66 and the subsequent 66.0.1 pwn2own chemspill, we decided 
to delay the deployment of the change. We are now ready to deploy the new bug 
type and regressions/regressed-by fields to production Bugzilla later this week.

A one-time bug type auto migration will follow this weekend. It will be done 
with a component-based migration script [1] as well as the bugbug machine 
learning tool [2]. Marco tested bugbug with several bugs on the staging server 
last weekend and the results look good overall. The current instance can be 
seen on: https://bugzilla.allizom.org/

It should be noted that bugbug only classifies bugs as defect or enhancement 
over the last 2 years, because the accuracy of the detection between 
enhancement and task is not perfect. So triage owners and/or assignees will 
have to manually change the type of some existing bugs from enhancement to task 
once the migration is complete.

We’ll keep you posted.
-Kohei

[1] https://github.com/mozilla-bteam/bmo/pull/1106/files
[2] https://github.com/mozilla/bugbug


On 2019-03-12 6:55 a.m., Sylvestre Ledru wrote:

Bugzilla is one of the key tools used for the development of Firefox since the 
Netscape era. Even though this tool is serving us well, after interviewing a 
bunch of people at every level inside the company, we realized that we need to 
go the extra step.


Therefore, we decided to focus on improving Bugzilla itself but also, as a next 
step, improve the workflows we have on bugs.


To start with, we are coming with a set of three major changes to make our life 
better and easier.


1) Enforcing the usage of the priority field


As described in this schema 
<https://docs.google.com/drawings/d/1G8SV3EUPknh-2zExL08cd9lzzGMOHAZeRA1geBQnGD4/edit>,
 we are now asking triage owners to set the priority field according to the priority 
definition 
<https://mozilla.github.io/bug-handling/triage-bugzilla#how-do-you-triage>. The main 
goal is to make sure that every bug has been looked at and a priority has been set in 
accordance with the priority definitions.

A bot will automatically needinfo the triage owner (or a member of the team if 
it uses a round robin triage method).

We have been experimenting with this for several components and the results 
look great!


2) Bug type - new field

Firefox development requires a bug for every change in the Firefox code base. 
It doesn’t matter if this is used to fix a defect in the product, to implement 
a new feature or to refactor some code.


For years, we have been using bugzilla keywords to classify them. However, as 
they are not mandatory, the metadata can be missing, unmaintained, or 
inconsistent.


With this change, we are going to extend Bugzilla to add a new field with three 
new values:

  *

    Defect - an issue in one of our products

  *

    Enhancement - a new feature or an improvement

  *

    Task - a developer task. For example: refactor code foo.


Since we don’t want to increase the confusion for new users, the default value will 
be defectand, to the best of our ability, existing bugs will be moved 
<https://bugzilla.mozilla.org/show_bug.cgi?id=1524738>under one of these 
categories.


With this information, we will be able to more precisely measure the quality of 
our products, as we will not mix defects together with feature-related work.


We have a development instance of Bugzilla 
<https://bugzilla-dev.allizom.org/>where the changes can be evaluated, we are 
planning to go live in the new few weeks.


More information https://bugzilla.mozilla.org/1522340


3) Adding a new field called “Regressed by”

Currently, we misuse the blocks/depends fields to mark bugs causing 
regressions. However, they can be confusing and aren’t used consistently by 
developers. Moreover, since we are using bugs for defects, enhancements or 
tasks, it can be very hard to pinpoint the changes which introduced a 
regression.

Being able to pinpoint changes which introduced regressions will make it easier 
to build tools to help with assessing the riskiness of changes.


Therefore, we will add a new field in bugzilla which will clearly identify 
which bug caused a regression.

More:

http://bugzilla.mozilla.org/1461492


Last but not least, nothing is written in stone and we have other improvements 
(bug workflow, improved search, regression field, etc) coming. Sylvestre


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Kohei Yoshino]

The User Story field will be soon removed from the new bug page.
https://bugzilla.mozilla.org/show_bug.cgi?id=1525376

-Kohei

On 2019-03-12 1:47 p.m., Daniel Veditz wrote:

The "User Story" field can be (ab?)used for all those things. If the bug is
not an "enhancement" it's likely blank and just waiting to be filled with a
good summary.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Kohei Yoshino]

Yes! You can use “type” like this:

https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:defect
https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:enhancement
https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:task

And “regressed_by” and “regressions” should also work.

-Kohei


On 2019-03-12 1:43 p.m., Daniel Veditz wrote:

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:


2) Bug type - new field
3) Adding a new field called “Regressed by”



Will the new fields be searchable using quicksearch?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How do I file a bug?

[Kohei Yoshino]

Sorry, I pushed the Send button too quickly, and my message was wrongly 
nuanced. I didn’t have any intention to complain; as a contributor working in 
the WebDev and UX areas, I’d rather like to help here. I have been doing some 
research on Mozilla web properties (that’s why I could provide a list of the 
relevant sites) [1], and even made a quick mock-up of an improved page several 
years ago. And as mentioned earlier, improving the Bugzilla onboarding 
experience is on my 2019 to-do list. I’m more than happy to discuss the matter 
with the stakeholders online or in person at All Hands!

-Kohei

[1] 
https://docs.google.com/spreadsheets/d/1Vh8lAXh7cQ5VVBW8EWu7pTA1EaNVvpVplLFGPBELRHw


On 2018-10-08 2:58 PM, Jared Hirsch wrote:

Hey all,

A big part of attracting and retaining great contributors is the tone we set 
when we talk to one another.

If you see a problem and want to make things better, then you should come up 
with a solution, and also do your best to communicate it effectively to the 
relevant people. (Bonus points for volunteering to help implement the fix, even 
if it turns out to be different from the solution you proposed.) This is an 
effective way to make actual progress. Calling out team A on team B's mailing 
list is not.

If you want to understand why things are the way they are, and propose 
solutions to the problems that you see, you can connect with different teams 
within Mozilla via their public discussion forums, like the Participation 
team's Discourse instance[1] or the dev-webdev list[2]. The Mozilla wiki has 
pages for all these teams, and is a good starting point.

I also want to point out that Mozilla activities are governed by the community 
participation guidelines. Note that "Be Respectful" is the first guideline 
listed: https://www.mozilla.org/about/governance/policies/participation/

Let's work together to build a positive, welcoming community, and help each 
other to stay focused on solving problems in a constructive manner.

Cheers,

Jared

[1] https://discourse.mozilla.org/tags/c/mozillians/participation
[2] https://lists.mozilla.org/listinfo/dev-webdev


On Thu, Oct 4, 2018 at 6:43 PM Kohei Yoshino mailto:kohei.yosh...@gmail.com>> wrote:

As a longtime contributor, I’m also concerned about the current situation. 
The contribution starting point (or Mozilla’s information architecture in 
general) is a total mess.

https://www.mozilla.org/en-US/contribute/signup/
https://codetribute.mozilla.org/
https://activate.mozilla.community/
https://campus.mozilla.community/
https://foundation.mozilla.org/en/participate/
https://mozilla.github.io/webdev/
https://www.whatcanidoformozilla.org/

and that’s not all. The Participation team should be doing a much better 
job here.

Speaking to Bugzilla where I’m volunteering as a UX designer, improving the 
onboarding experience for both contributors and new Mozilla employees is one of 
my goals in 2019 [1], but it will be possible only when stakeholders are 
involved.

[1] 
https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap#even-more

-Kohei


On 2018-10-04 8:41 PM, Mike Hommey wrote:
 > On Thu, Oct 04, 2018 at 05:14:47PM -0700, fantasai wrote:
 >> On 10/04/2018 04:26 PM, Steve Fink wrote:
 >>> On 10/04/2018 03:45 PM, fantasai wrote:
 >>>> Start here, at Mozilla's home page:
 >>>> https://www.mozilla.org/
 >>>>
 >>>> Give me steps to reproduce to find instructions for filing
 >>>> a bug against Firefox. Ditto for up-to-date instructions
 >>>> for building the source and submitting a patch.
 >>>>
 >>>> (Don't send me links to the instructions; I'm cheating by
 >>>> asking here already. Walk me through the process of
 >>>> discovering how I can contribute to Mozilla and make the
 >>>> world a better place. I wouldn't be here if I hadn't
 >>>> already walked that path 19 years ago, but I can't find it
 >>>> anymore so I need some help.)
 >>>
 >>> I tried it out, and did better than I expected on my first run-through:
 >>> [...]
 >>
 >> I'm impressed! Want to take a stab at finding patch-submission
 >> instructions? :D
 >>
 >>> I agree that a nice path from www.mozilla.org <http://www.mozilla.org> 
would be beneficial,
 >>> especially for promoting the volunteer aspect of the project.
 >>
 >> We've got a lot of highly-produced (read: expensive) material
 >> promoting the volunteer aspect of Mozilla:
 >> https://www.mozilla.org/en-US/contribute/
 >> But afaict none of it actually leads to a viable path towards
 >> actually becoming a technical contrib

Re: How do I file a bug?

[Kohei Yoshino]

As a longtime contributor, I’m also concerned about the current situation. The 
contribution starting point (or Mozilla’s information architecture in general) 
is a total mess.

https://www.mozilla.org/en-US/contribute/signup/
https://codetribute.mozilla.org/
https://activate.mozilla.community/
https://campus.mozilla.community/
https://foundation.mozilla.org/en/participate/
https://mozilla.github.io/webdev/
https://www.whatcanidoformozilla.org/

and that’s not all. The Participation team should be doing a much better job 
here.

Speaking to Bugzilla where I’m volunteering as a UX designer, improving the 
onboarding experience for both contributors and new Mozilla employees is one of 
my goals in 2019 [1], but it will be possible only when stakeholders are 
involved.

[1] https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-7-Roadmap#even-more

-Kohei


On 2018-10-04 8:41 PM, Mike Hommey wrote:

On Thu, Oct 04, 2018 at 05:14:47PM -0700, fantasai wrote:

On 10/04/2018 04:26 PM, Steve Fink wrote:

On 10/04/2018 03:45 PM, fantasai wrote:

Start here, at Mozilla's home page:
   https://www.mozilla.org/

Give me steps to reproduce to find instructions for filing
a bug against Firefox. Ditto for up-to-date instructions
for building the source and submitting a patch.

(Don't send me links to the instructions; I'm cheating by
asking here already. Walk me through the process of
discovering how I can contribute to Mozilla and make the
world a better place. I wouldn't be here if I hadn't
already walked that path 19 years ago, but I can't find it
anymore so I need some help.)


I tried it out, and did better than I expected on my first run-through:
[...]


I'm impressed! Want to take a stab at finding patch-submission
instructions? :D


I agree that a nice path from www.mozilla.org would be beneficial,
especially for promoting the volunteer aspect of the project.


We've got a lot of highly-produced (read: expensive) material
promoting the volunteer aspect of Mozilla:
   https://www.mozilla.org/en-US/contribute/
But afaict none of it actually leads to a viable path towards
actually becoming a technical contributor...

 From my discussions with staff at Mozilla, the people actually
working with volunteers (like QA and l10n) find this very
frustrating, but the people whose job it is to connect volunteers
to opportunities to contribute don't think it's useful, important,
or in some cases even a good idea to fix this problem. I don't
know how to break through that resistance, and I find it very
demoralizing that there even is any. :(

I'm also disconnected enough from Mozilla the last few years
that I've no idea where up-to-date documentation on this stuff
would live. If I ever manage to dig myself out of the backlog
of spec work enough to write a patch, I'd like to know where
to look!

Fwiw, here's how I arrived at becoming a technical contributor:
   https://web.archive.org/web/2125153750/http://www.mozilla.org:80/
   
https://web.archive.org/web/2301043132/http://www.mozilla.org:80/get-involved.html

https://web.archive.org/web/2302035824/http://www.mozilla.org:80/quality/bug-writing-guidelines.html
   
https://web.archive.org/web/2304015940/http://www.mozilla.org:80/newlayout/bugathon.html


I gave a shot at a generic "I want to contribute" approach of the web
site.

Starting from https://www.mozilla.org, there's a "Get Involved" link at
the top, which leads to https://www.mozilla.org/en-US/contribute/, which
has another "Get Involved" button... which leads to
https://www.mozilla.org/en-US/contribute/signup/, a disappointing list of
3 simple items, 3 "more challenging" items, and ... nothing else.

And what items:
- simple
   - Connect with Mozilla on Twitter
   - Use Firefox on your phone
   - Discover why we can't live without encryption

- more challenging:
   - watch someone live hack on Firefox
   - Learn a bit about coding (which is disappointingly a link to
 developer tools challenger)
   - Start using the Mozilla Sumbler app

Why there's no link to https://codetribute.mozilla.org/ is beyond me
(and it does not help to get to filing new bugs, though)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: Visibility of window.content to untrusted code

[Kohei Yoshino]

A similar story: `window.controllers` was removed with Firefox 29 but added 
back to Firefox 30 because it had been widely used for UA detection. 
`window.content` might cause the same compatibility issue, but anyway, it's 
difficult to guess the impact from GitHub search results...

https://www.fxsitecompat.com/en-CA/docs/2014/window-content-controllers-pkcs11-and-loadstatus-have-been-removed/

-Kohei


On 2017-09-12 5:04 PM, Emilio Cobos Álvarez wrote:

Just for the record, since I got curious and I saw no mention in the
intent email:

I've noticed that this may be used pretty easily for UA detection. So
far [1] is the only remotely related thing I've found from a search on
Google and GitHub (outside of the firefox codebase ofc).

I suspect keeping it exposed may cause more compat issues than removing
it, and given finding _something_ was super hard I suspect this is
pretty safe to remove, but if someone wants to take a closer look,
that'd also be great, I guess.

It'd have been great to have a counter on how many times the property is
accessed from a content doc or something, but I guess it may not be
totally representative, I've seen too much code iterating over the
window properties... :P

Anyway, great to remove another non-standard feature from content
documents :)

  -- Emilio

[1]: http://forums.mozillazine.org/viewtopic.php?f=25=232754

On 09/12/2017 09:32 PM, Boris Zbarsky wrote:

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=864845

window.content is a Gecko-specific thing that basically acts like
window.top in untrusted code.  In chrome it returns the currently
selected tab, effectively.

I would like to unship window.content for 57; no one else implements it.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to disable service workers and push in 52 ESR

[Kohei Yoshino]

Do we already have a bug for this? Firefox 52 will be shipped just in 4 weeks.

On 2017-01-18 10:49 AM, Ben Kelly wrote:

I'd like to disable service workers in 52 ESR.  This would also require
disabling push notifications.

A year ago we decided to disable service workers in 45 ESR because it was
very new and unstable:

https://groups.google.com/forum/#!msg/mozilla.dev.platform/yuNHtDhl3lY/VWXOa8N9AgAJ

While things have stabilized since then we are in process of making a major
architectural change in order to support multiple content processes
(multi-e10s).  This will make it very difficult to uplift fixes.  Once the
new architecture has stabilized we should be able to enable SW in the next
ESR.

Thoughts?


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing navigator.buildID?

[Kohei Yoshino]

So the Battery Status API has just been removed, I think now is a good time to 
think about navigator.buildID again, which bug [1] has been inactive for a 
whole year.

4 years ago, Firefox 16 removed a minor version number from the user agent 
string to mitigate fingerprinting [2][3]. However, the build ID unique to each 
minor version is still exposed via the non-standard navigator.buildID property. 
Since trackers can easily retrieve build IDs from Mozilla Wiki [4] to map them 
to minor version numbers, the fix in Firefox 16 was totally meaningless.

There were some legitimate use cases on Mozilla properties, for example, 
warning visitors who are using an outdated Firefox, but those usages have been 
replaced with the UITour API [5]. A comment in the bug [1] explains that 
Netflix was also using the build ID to detect a specific playback bug in 
Firefox, but it's probably not longer relevant. Given that, I believe the 
buildID property should be removed, or at least made chrome-only.

Thoughts?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=583181
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=728831
[3] 
https://www.fxsitecompat.com/en-CA/docs/2012/ua-string-no-longer-contains-patch-level-version-number/
[4] https://wiki.mozilla.org/Releases/Firefox_49/Test_Plan#Milestones
[5] https://bedrock.readthedocs.io/en/latest/uitour.html

-Kohei
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Context3D not available

[Kohei Yoshino]

It's a known issue. See 
https://www.fxsitecompat.com/en-CA/docs/2016/flash-is-forced-windowless-mode-on-firefox-for-64-bit-windows-affecting-stage-3d/
 for details.

On 2016-09-06 6:21 AM, witchhazel...@gmail.com wrote:

Context3D not available! Possible reasons: wrong wmode or missing device 
support.only comes up on some games


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kohei Yoshino]

Today's announcement from Mozilla:
https://blog.mozilla.org/futurereleases/2016/04/29/update-on-firefox-support-for-os-x/

The decision is fine but why don't they update this thread? (I know, Mozilla is 
very bad at communication.)

-Kohei
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform