631507 - File upload file picker on addons.mozilla.org/en-US/developer does not appear

Status: RESOLVED WONTFIX

(addons.mozilla.org Graveyard :: Developer Pages, defect, P5)

Description

[Alice0775 White]

Attachment: screen shot

Build Identifier:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110203 Firefox/4.0b12pre ID:20110203010203

Very similar  Bug 626378.

The file picker appears when I click "Select a File" button.

if I disable Site Style(View > Page Style > No Style),
The file picker appears when I click Browse... button.

Comment 1

[Wil Clouser [:clouserw]]

Can you be more specific about what the bug is and the steps to reproduce?

Comment 2

[Alice0775 White]

(In reply to comment #1)
> Can you be more specific about what the bug is and the steps to reproduce?

[STR]
Click the "Select a File" button

[Actual result]
Nothing happen

[Expected result]
A file picker pops up.

Comment 3

[Wil Clouser [:clouserw]]

Please try this with a new profile and no add-ons.

Comment 4

[Alice0775 White]

(In reply to comment #3)
> Please try this with a new profile and no add-ons.
I reported here new profile and noaddon in about:addons.

Comment 5

[Wil Clouser [:clouserw]]

Please load "about:support" and paste in the result

Comment 6

[Alice0775 White]

  Application Basics

        Name
        Firefox

        Version
        4.0b12pre

        User Agent
        Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre

        Profile Directory

          Open Containing Folder

        Enabled Plugins

          about:plugins

        Build Configuration

          about:buildconfig

  Extensions

        Name

        Version

        Enabled

        ID

  Modified Preferences

      Name

      Value

        accessibility.typeaheadfind.flashBar
        0

        browser.places.importBookmarksHTML
        false

        browser.places.importDefaults
        false

        browser.places.leftPaneFolderId
        -1

        browser.places.smartBookmarksVersion
        2

        browser.startup.homepage_override.buildID
        20110204030345

        browser.startup.homepage_override.mstone
        rv:2.0b12pre

        dom.report_all_js_exceptions
        true

        extensions.checkCompatibility
        false

        extensions.checkCompatibility.3.6
        false

        extensions.checkCompatibility.3.6a
        false

        extensions.checkCompatibility.3.6b
        false

        extensions.checkCompatibility.3.6pre
        false

        extensions.checkCompatibility.3.7
        false

        extensions.checkCompatibility.3.7a
        false

        extensions.checkCompatibility.3.7b
        false

        extensions.checkCompatibility.4.0
        false

        extensions.checkCompatibility.4.0b
        false

        extensions.checkCompatibility.4.0pre
        false

        extensions.lastAppVersion
        4.0b12pre

        javascript.options.strict
        true

        network.cookie.prefsMigrated
        true

        places.history.expiration.transient_current_max_pages
        128823

        privacy.sanitize.migrateFx3Prefs
        true

        security.warn_viewing_mixed
        false

  Graphics

        Adapter Description
        ATI Radeon HD 4300/4500 Series

        Vendor ID
        1002

        Device ID
        954f

        Adapter RAM
        512

        Adapter Drivers
        aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.812.0.0

        Driver Date
        1-4-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7600.20830, font cache n/a)

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

        GPU Accelerated Windows
        1/1 Direct3D 10

Comment 7

[Wil Clouser [:clouserw]]

Maybe this is due to WOW64.  Are you able to try it in 32 bit?

Comment 8

[Kumar McMillan [:kumar]]

Is this a nightly build or built from a custom branch?  I'm curious because latest beta is 10 and I thought nightly would be at 4.0b11pre

Comment 9

[Alice0775 White]

(In reply to comment #7)
> Maybe this is due to WOW64.  Are you able to try it in 32 bit?
I am using 32bit version of Minefield.
Do you mean 32bit OS?

(In reply to comment #8)
> Is this a nightly build or built from a custom branch?  I'm curious because
> latest beta is 10 and I thought nightly would be at 4.0b11pre

It is nightly which is downloaded  from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

Comment 10

[Wil Clouser [:clouserw]]

(In reply to comment #9)
> (In reply to comment #7)
> > Maybe this is due to WOW64.  Are you able to try it in 32 bit?
> I am using 32bit version of Minefield.
> Do you mean 32bit OS?

You're running a 32 bit app on a 64 bit OS.  That's an uncommon setup and since no one else can reproduce these bugs, that's my next guess at the problem.  You could try the 64-bit version of minefield, or try your current version with a 32 bit OS.  It sounds like you might have found a bug with the browser.

Comment 11

[Alice0775 White]

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > Maybe this is due to WOW64.  Are you able to try it in 32 bit?
> > I am using 32bit version of Minefield.
> > Do you mean 32bit OS?
> 
> You're running a 32 bit app on a 64 bit OS.  That's an uncommon setup and since
> no one else can reproduce these bugs, 

It is a thing heard of for the first time.
Uncommon? 
I dont think so.
See http://forums.mozillazine.org/viewtopic.php?f=23&t=2093681
Almost nightly tester used Windows7 x 64bit + Minefiled 32bit.

Comment 12

[Alice0775 White]

Attachment: reduced html

File upload picker would not pop up on Minefield.

[STEP TO REPRODUCE]
1. Start Minefield with *NEW PROFILE* and *NO ADDON*
2. Open attached reduced html
3. Click a link "Select a File"

[ACTUAL RESULT]
No thing happen.

[EXPECTED RESULT]
File upload picker pops up


Work:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110205 Firefox/4.0b12pre ID:20110205030343


Not work:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110205 Firefox/4.0b12pre ID:20110205030343

Comment 13

[Alice0775 White]

Sorry. correct.

Work:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15pre) Gecko/20110202 Namoroka/3.6.15pre ID:20110202181307

Not work:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110205
Firefox/4.0b12pre ID:20110205030343

Comment 14

[Alice0775 White]

Regression window(cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/52c2f34cd686
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre ID:20101107143503
Fails:
http://hg.mozilla.org/mozilla-central/rev/c17742be31fb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101107 Firefox/4.0b8pre ID:20101107231618
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=52c2f34cd686&tochange=c17742be31fb

Comment 15

[Alice0775 White]

It works if I set gfx.direct2d.disabled to true.

Comment 16

[Alice0775 White]

In localbuild,
build from c17742be31fb : fails
build from 5ea89aae98b5 : fails
build from 30b315c5be6a : works
build from 9b79a3d0c554 : works
build from 52c2f34cd686 : works

Regressed by:
5ea89aae98b5	Masayuki Nakano — Bug 548964 [DW] bottom of spellchecker underline isn't painted in <input> element with some fonts r=jfkthame, a=joe

Comment 17

[Alice0775 White]

WORKAROUND, put the followings in userContent.css.

.invisible-upload:hover input { 
  font-size: inherit !important;
}

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #16)
> In localbuild,
> build from c17742be31fb : fails
> build from 5ea89aae98b5 : fails
> build from 30b315c5be6a : works
> build from 9b79a3d0c554 : works
> build from 52c2f34cd686 : works
> 
> Regressed by:
> 5ea89aae98b5    Masayuki Nakano — Bug 548964 [DW] bottom of spellchecker
> underline isn't painted in <input> element with some fonts r=jfkthame, a=joe

I disagree, the bug must not cause this bug. Bug 548964 did just correct the computing of internalLeading value. I think that the patch may have changed only the condition for reproducing this bug on DW environment.

We should log what DOM events are handled by the input element...

And looks like the CSS is very hacky, why don't we use js?

Comment 19

[Alice0775 White]

(In reply to comment #18)
>I disagree, the bug must not cause this bug. Bug 548964 did just correct the
>computing of internalLeading value. I think that the patch may have changed
>only the condition for reproducing this bug on DW environment.

I agree with you.
This problem is completely the site issue.

> And looks like the CSS is very hacky, why don't we use js?

I do not know, this site is hosted by addons.mozilla.org.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Taking a total guess at the right component, but this should certainly be in the AMO product.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The mousedown, mouseup and click events targeted <a> element when DW is enabled. But otherwise, they targeted the <input>. So, it seems that the hit test failed but I'm not sure the reason.

Comment 23

[Alice0775 White]

Attachment: different gap sample

Comment 24

[Alice0775 White]

Attachment: different gap screen shot

Left side is Minefield(H.A on), right side is Namoroka.

different gap, why?

Comment 25

[Alice0775 White]

I confirmed that the extra gap is introduced by cset 5ea89aae98b5.

I think that the input element was not able to catch a mouse event because there is this gap.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

On my environment (I can reproduce this bug), the internalLeading is computed as 1px with DW, but 0px with GDI.

Comment 27

[Wil Clouser [:clouserw]]

Can someone summarize what AMO can do to fix this bug?

Comment 28

[Boris Zbarsky [:bzbarsky]]

Comment 17 has a rule you could add.

But in general, it sounds like your CSS is assuming things about font metrics that are just not true.  The usual solution is to use less CSS.  I know that sounds flippant, but that's the best I can do without trying to understand your stylesheets in detail...

Comment 29

[Alice0775 White]

This still happens with clean profile(Of course, no addon, disabled all plugins) on 
http://hg.mozilla.org/mozilla-central/rev/1881f9b5f8b5
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110819 Firefox/9.0a1 ID:20110819030749

On Linux, it works.

Comment 30

[Alice0775 White]

Almost 2 year. Nothing improved.

The AMO site is still BROKEN COMPLETELY.

Comment 31

[Alice0775 White]

Severity
    This field describes the impact of a bug.
    blocker 	Blocks development and/or testing work
    critical 	crashes, loss of data, severe memory leak
    major 	major loss of function
    normal 	regular issue, some loss of functionality under specific circumstances
    minor 	minor loss of function, or other problem where easy workaround is present
    trivial 	cosmetic problem like misspelled words or misaligned text
    enhancement 	Request for enhancement

I think this is not trivial, because this bug is loss of functionality.

Comment 32

[Alice0775 White]

FYI,
The patch in Bug 345195 Comment 68 seems to fix this problem.

Comment 33

[Wil Clouser [:clouserw]]

Thanks for filing this.  Due to resource constraints we are closing bugs which we won't realistically be able to fix.  If you have a patch that applies to this bug please reopen.

For more info see http://micropipes.com/blog/2014/09/24/the-great-add-on-bug-triage/