I had similar yesterday and it bugged the hell out of me for an hour. In
the end, it turned out to be a missing owsbroswer.js. The little left and
corner icon had been showing a "page loaded with errors" and the detail said
that "brosweris is undefined."

Anyhow, I found and replaced an owsbrowse.js and life went back to good
(after of course I deleted files in IE and iisreset). I have (am) messing
with the client side scripts, and I do recall deleting the owsbrose.js at
some point in my confusion caused by not 'deleting files' in IE after
client-side script changes.

Doesn't sound like your same issue, but this experience of mine may give you
a needed hint - this could be a client-side programming issue.

You’ve got one part right: “it bugged the hell out of me for an hour”… I’m going on #3 right now…

This isn’t the same issue… I have no JS errors. Also, I’d expect to see this for all users hitting this list, not just one isolated person (and all testing  is coming from a single server).

Try the &contents=2 trick  to get the list  of web parts on the page and look for the list form  web part on the page. Reset the personalization data if necessary. It’s technically possible to personalize a list page…

I've seen this once before but don't have any valuable insight to give
you.

Is the Web based upon a custom site definition?
Has the SCHEMA.XML file been changed in any way?
Has the listview page in question  been unghosted?
Has the ows.js file or the owsbrowse.js file been altered?
If there a CustomJSUrl file?

If you create a new web and create a new list  does the problem persist?

Saved the list  as a template, added  it to the gallery of a totally different portal  (same site definition, same server, same farm), created a new list based off the template, and got the exact same results.

I was having another issue  and when I saw this behavior, I thought it was the root cause… apparently not though as I was able to fix my other issue while this remains a problem. Now it’s  more of a curiosity as to why it’s happening.

I’ve seen similar things like this. The workaround that I try first is to ensure the portal/VS URL is in the trusted sites in the local browser. Don’t ask me why…

This is a puzzling one indeed. I’ve never seen it before, but here are perhaps a few things you could try.

Did you check the security permissions on the included .js files? Perhaps there is a security setting  on one of those files that would prevent just that one user  from accessing the underlying JavaScript. I don’t  expect that this would be it, because if it was, I would expect there to be either JavaScript errors (which you said you did not have) on the page or a login  prompt. But, it may be worth checking anyway.

Another thing  you could try is checking the user’s JavaScript settings under Internet Options in IE. That is one thing that could be different for that user account. The textboxes are all created by calls to JavaScript functions, so perhaps JavaScript calls are disabled?

Finally, look through the HTML source code of the page, as well as your style-sheet file for any references to ms-formbody. This class is used for all text box  fields. Perhaps there is something causing the class to be hidden.

I know none of these offer solutions, but maybe you can at least find some clues from these ideas.

We had something similar. It happened to two different users. One was a Contributor on a Document Library but could not open a folder in that library. The other was a Contributor on antoher Document Library and could upoad a document but could not edit it.

I donb't know why but ihn both cases the browser settings Tools->Internet Options->Advanced for Disable Script Debugging (Other) was cheked. Once it was unchecked, things worked properly.

The component that isn't rendering properly is a List Form Web Part. I
suspect the black box  source code embedded in it. Perhaps you could try
editing the page in FrontPage and customizing the Web Part (right click
on the Web Part and choose "Customize SharePoint List Form" from the
context menu). This gets to the heart of the displaying of fields. Make
a few changes. See the impact on the odd user's view of the page. Then
go back to the original display (right click on the Web Part and choose
"Revert SharePoint List Form" from the context menu). Again, see the
impact. Then reghost that page.

It may be a wild goose chase but you may learn something about the
situation.