1053171 - Text fields are not displayed

Status: RESOLVED DUPLICATE of bug 1053398

(Core :: General, defect)

Description

[luca892]

Attachment: input[#text].PNG

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; rv:11.0) like Gecko

Steps to reproduce:

If you open sites that contains input type=text fields, they doesn't appear. (i had to use another browser to open that ticket)
Take a look at the image i attach. I have this problem from the patch of today.

Comment 1

[Cork]

Could you try starting firefox in safe mode?

https://support.mozilla.org/en-US/kb/Safe+Mode

Comment 2

[luca892]

I did it. I can see them again in safe mode

Comment 3

[luca892]

they appear again before restart firefox again if i restart in safe mode or disable/enable adblock (that is the only addon i've)

Comment 4

[:Gijs (he/him)]

(In reply to luca892 from comment #3)
> they appear again before restart firefox again if i restart in safe mode or
> disable/enable adblock (that is the only addon i've)

So when you're not in safe mode, if you disable adblock from about:addons, things work again? That sounds like a problem with adblock... is this adblockplus?

Comment 5

[luca892]

No i mean if i disable adblock or restart in safe mode, the first time i restart Firefox i see inputs again. If i restart it once more i cant ( adblock is still disabled )

Comment 6

[:Gijs (he/him)]

You're on nightly, right? Can you try to get a regression range? ( http://mozilla.github.io/mozregression/ ) This shouldn't take very long if it's as recent as you say, and will help a lot in tracking down how this broke.

Comment 7

[luca892]

Yes i'm on nightly, i'm going to do it as soon as i get back home

Comment 8

[luca892]

Attachment: test.PNG

it was the 1st time that i use that program but i had a problem, i wrote:
mozregression --good=2014-08-12 --bad=2014-08-13 and it told me that x64 bit versions werent available. I added --bit=32 like the program suggested me.

Comment 9

[luca892]

i tested right now the latest x86 version of nightly and there is the same problem

Comment 10

[:Gijs (he/him)]

(In reply to luca892 from comment #9)
> i tested right now the latest x86 version of nightly and there is the same
> problem

Right... so the odd thing is that the regression range you found is empty - you didn't seem to find any builds which were "bad", as far as I can tell... perhaps this is because it's never the first startup when you're using mozregression?

Comment 11

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch (intermittently here 14-15 August; then away until 19th) from comment #10)
> perhaps this is because it's never the first startup when you're using
> mozregression?

err, *always* the first startup, I meant - mozregression uses a new profile unless you specify otherwise...

Comment 12

[Wladimir Palant]

Or because the problem is profile-specific - and mozregression will always create a new profile by default.

For reference: A bad Adblock Plus filter like "##input" *could* cause issues like what's described here but that wouldn't stay if Adblock Plus is disabled. Also, Adblock Plus won't apply to special pages like about:home.

Comment 13

[:Gijs (he/him)]

(In reply to Wladimir Palant from comment #12)
> Or because the problem is profile-specific - and mozregression will always
> create a new profile by default.

This is another good point - I should have asked before - can you try creating a new profile, and seeing if you can reproduce there?

(we would probably still want to figure out why things are broken on your existing profile, but it'll help in debugging what the issue is...)

Comment 14

[luca892]

Attachment: google search bar.png

I don't know if that is linked with the problem we're talking about but it's about a week i've met this issue just on Google search bar too.

Comment 15

[luca892]

Regarding the Google search bar bug the latest version that wasnt giving problem was 2014-08-08 18f408a5984e
it started from 2014-08-09 83f519eb1a3a.

Comment 16

[Wladimir Palant]

(In reply to luca892 from comment #14)
> I don't know if that is linked with the problem we're talking about but it's
> about a week i've met this issue just on Google search bar too.

This is something I can reproduce, meaning: definitely a different issue.

Comment 17

[d.a.]

Some notes:

The input still exists in the DOM and you can access it with the inspector. When checking it's dimensions it will show a negative width and height. Margin, border and padding will have the correct values as applied by the CSS.

Changing the input to type number will make the field appear, as will range, button and submit. Setting it to text, email password or an undefined type (that would appear as a textfield, per spec) will not render the field. 

I was able to get it to draw the textfield as it should by a few steps (with the inspector)

1. Change the type to number
2. Write something in the field
3. Add two new CSS rules:
-moz-appearance: textfield
-moz-binding: url(chrome://global/content/bindings/textbox.xml#textbox)
4. Change the type back to text

I did the above a couple of times and it brought the field back.

Comment 18

[:Gijs (he/him)]

(In reply to Wladimir Palant from comment #16)
> (In reply to luca892 from comment #14)
> > I don't know if that is linked with the problem we're talking about but it's
> > about a week i've met this issue just on Google search bar too.
> 
> This is something I can reproduce, meaning: definitely a different issue.

Indeed, this is bug 1051511.

I wonder if this could be related to bug 1050049... Bobby, could you have a look (see also: comment #17)

Comment 19

[:Gijs (he/him)]

I can reproduce this on today's nightly on Windows as well as OS X. Should have tried restarting several times before now :-\

Comment 21

[Elbart]

One way to "corrupt" a new profile is to start and close Firefox twice without doing anything, and then starting it again. On the third opening, the searchbar on about:home should be gone.

Comment 22

[Elbart]

Yep: https://bugzilla.mozilla.org/show_bug.cgi?id=1053398

Comment 23

[:Gijs (he/him)]

Forward duping by exception because the other bug has the regression already marked.

Comment 24

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598