682596 - Add-on bar text appears greyed-out

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect)

Description

[George]

Attachment: Aurora_2011-08-27.png

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a2) Gecko/20110827 Firefox/8.0a2
Build ID: 20110827042014

Steps to reproduce:

Install my Add-on SDK add-on Canadian Weather, which can display text content in add-on bar. 


Actual results:

Text color appears greyed-out.


Expected results:

Text should be black. Problem does not appear in other toolbars, or in other Firefox channels (release, beta and nightly). The displayed content is a text node within a span element.

Comment 1

[George]

Attachment: How it appears in Firefox 6

Comment 2

[George]

Seems I can't reliably reproduce this :(

Comment 3

[Tim (fmdeveloper)]

Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

Please post the graphics section from about:support

Comment 4

[George]

Ok I can reproduce this reliably using the Add-on SDK cfx command-line tool (each run creates a new profile). Only occurs in Firefox 8.0a2. Safe Mode would disable the add-on that demonstrates the problem. I don't think the problem occurs with XUL-based add-ons. I will post in the jetpack group and point them here. Here is the graphics info you requested:

  Graphics

        Adapter Description
        Mobile Intel(R) 4 Series Express Chipset Family

        Vendor ID
        8086

        Device ID
        2a42

        Adapter RAM
        Unknown

        Adapter Drivers
        igdumd64 igd10umd64 igdumdx32 igd10umd32

        Driver Version
        8.15.10.2302

        Driver Date
        2-11-2011

        Vendor ID (GPU #2)
        8086

        Device ID (GPU #2)
        2a43

        Adapter RAM (GPU #2)
        Unknown

        Adapter Drivers (GPU #2)
        igdumd64 igd10umd64 igdumdx32 igd10umd32

        Driver Version (GPU #2)
        8.15.10.2302

        Driver Date (GPU #2)
        2-11-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)

        GPU Accelerated Windows
        1/1 Direct3D 10

Comment 5

[George]

I have narrowed this down, problem first appears in nightly:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0a1) Gecko/20110813 Firefox/8.0a1

Comment 6

[George]

Contrary to my original report, testing with cfx shows this bug still exists in latest nightly
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110828 Firefox/9.0a1

Comment 7

[George]

Believe now this is an Add-on SDK bug.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

Matteo: can you take a look at this and see if you can reproduce and, if so, whether it's an SDK bug or a platform bug?

Comment 9

[George]

Just to clarify (and what caused my initial confusion), the problem does not appear in an installed xpi, only when using cfx run

Comment 10

[Matteo Ferretti [:zer0] [:matteo]]

Myk: I'm not able to reproduce it, I created a Widget and set a string as content and it works as expected, in the Nightly (Firefox/9.0a1) we have the text in black. Maybe there are other HTML element involved that caused this behavior. Or maybe is a specific CSS platform behavior (I'm already in travel so I don't have the Mac with Windows with me, at the moment).
However, is interesting that the grayed-out text doesn't appear in the xpi version. I'm not quite familiar how the cfx run works now, but I know we already planned to generate the xpi also in that case. Is something that we will land in the short term?

Comment 11

[Myk Melez [:myk] [@mykmelez]]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #10)
> However, is interesting that the grayed-out text doesn't appear in the xpi
> version. I'm not quite familiar how the cfx run works now, but I know we
> already planned to generate the xpi also in that case. Is something that we
> will land in the short term?

Hmm, good question, not sure.

Brian: how far out is that?

Comment 12

[George]

Another observation. I am testing with
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110901 Firefox/9.0a1
and using a minimal add-on with a main.js of

require("widget").Widget({
  id: "hello-display",
  label: "My Hello Widget",
  content: "Hello World!",
  width: 100
});

After the browser window opens, if I do either of:
1. Maximize browser, then Restore Down, string changes to black
2. Enable Menu bar, string changes to black

Comment 13

[Matteo Ferretti [:zer0] [:matteo]]

I actually did the same in my previous test, but on OS X the string is black from the beginning. So it could be a specific platform behavior, relate somehow to how cfx run works.
I'm afraid I can't test now on a Windows machine because I'm not at home. But let's see the Brian's reply as well.

Comment 14

[Brian Warner [:warner :bwarner]]

The "always build XPIs" feature is still several weeks out. I'd normally hope to get to it in the next 2ish weeks, but we've got the all-hands and the London workshop coming up, for which I've got a presentation to build, which is taking priority. So to be realistic I'd say mid-october.

Comment 15

[Myk Melez [:myk] [@mykmelez]]

We just landed "always build XPIs".  Does that "fix" the problem?

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Matteo, have you had a chance to look at this?

Comment 17

[Matteo Ferretti [:zer0] [:matteo]]

I usually always in travel and I have my MacBook Air with me that doesn't have a Windows partition. I asked to Alex if he can do a quick check to see if the problem still exists. If he cannot, or the problem still persist, I will find a Windows machine and I will check ASAP.

Comment 18

[Matteo Ferretti [:zer0] [:matteo]]

Alex tried the example from comment 12 and it is always black, even on 1.1a, so it's not reproducible apparently.

We should ask to the bug's reporter if the problem still persist in his environment.

Comment 19

[Myk Melez [:myk] [@mykmelez]]

Based on Alex's input, resolving this fixed.  But please reopen if you still see the problem!