Firefox formatting issue in Myspace




10 years ago
10 years ago


(Reporter: pepemanp, Unassigned)


Firefox Tracking Flags

(Not tracked)




(2 attachments)



10 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; Tablet PC 2.0; InfoPath.2; MAXTHON 2.0)

Internet Explorer and browers based on the Internet Explorer engine, as Maxthon, works fine with myspace pages, but Firefox don't work.

The problem is the compatibility, the pages don't format correctly, for example the html tables got missed or placed in a wrong position.

Reproducible: Always

Steps to Reproduce:
1. Going to my myspace profile:
Actual Results:  
Firefox is not compatible with myspace pages

Expected Results:  
Be compatible as many other browsers, Internet Explorer or Maxthon

Loading well the website

I marked the problem as major.

More then 200 million of people is using myspace (everyday grows with 230.000 new profiles), so myspace is comparable in extension to USA or Canada, if you dont find serious that your browser be unable to fulfill the expectances of all these people when they try to access their profiles, then is because we have a different way about how to appreciate the "severity of this"

So for me, it's very serious and I hope it be also for you.

Comment 1

10 years ago
Thank you for this report. However, in order to make it more useful, please follow the steps found at and report back with your results.
Severity: major → normal
Summary: FIREFOX DONT FORMAT WELL MYSPACE PROFILE PAGES → Firefox formatting issue in Myspace
Version: unspecified → 3.1 Branch
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008120122 Firefox/3.0.5

Confirmed. The content on the referenced page gets pushed down. Most probably tech evang, gonna put it there for now.
Assignee: nobody → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: general → english-us
Version: 3.1 Branch → unspecified
Sorry about that, seems like Chrome displays it correctly over to core->layout, I'll try to see what's going on.
Assignee: english-us → nobody
Component: English US → Layout
Product: Tech Evangelism → Core
QA Contact: english-us → layout
Definitely not a regression, I see the same with ff2. Gecko's layout is totally different than chrome's, although I'm not exactly sure why. Opera also parses this correctly, so confirming.

Reporter: can you create a minimized testcase that still reproduces this and attach it to this bug?
Ever confirmed: true
Keywords: testcase-wanted
This definitely is some js problem, from there source line 260:

// Now that 'win' is set appropriately, pass on the request.
  // Obscure Firefox bug sometimes causes an exception when xmlhttp is
  // utilized in an IFPC handler. Wrapping our handleRequest calls
  // with a setTimeout in the target window's scope prevents this
  // exception.
  // See this Mozilla bug for more info:
  // Also see this blogged account of the bug:
  var fn = function() {

and this function throws (while in opera and chrome it doesn't). Not sure if this is what the problem is, cc'ing Boriss, per bug 249843 comment 12.
So can someone create something resembling a testcase here?

For what it's worth, I'm not seeing an exception on the line mentioned in comment 5.
Interesting to note: with Firebug's script panel enabled I was only getting this.element is null error and not the one I mentioned before. Maybe someone from myspace can comment here as it is their code (and pretty complicated too). In general the site was throwing alot of errors in Firefox while Chrome and Opera don't have those errors (besides the few security errors, but they didn't really seem to matter). I tried reducing the site, but the errors are mostly xmlhttp related, so I'll have to setup a server to see if I can get a testcase going.
One interesting experiment is always to save page, complete in Firefox, then load the resulting markup in Safari or Opera with script turned off.

That at least tells us whether the problem is Gecko ending up with a different DOM, or laying out the same DOM differently.
It's a completely different DOM, I did that test already and Chrome will end up with the same layout as Gecko, which is why I blamed it on the js. I also checked the DOM in Firebug vs the DOM in Chrome (resource-viewer or whatever it's called) and confirmed this.
Ah, ok.

Looking at this code it really should work (and I don't see that code throwing over here, again; are they catching the exception or something?)
No they're not catching the exception. In the error console I get:

Error: element is null
Source File:
Line: 3972

Reliably, on two different computers (one with no extensions at all), you don't get *any* exceptions?
I'll also try to breakpoint on that line and look at the calling function to see what's going on later tonight.
Ah, ok.  I get the element is null exception, sure.
Created attachment 355789 [details]
unminimized testcase
Created attachment 355791 [details]

This seems like a duplicate of bug 364188.
Nice catch, that would definitely be the problem on this page, the wrap div gets closed and thereby pushes everything down. I was just chasing my tail with my comments above, sorry for the misdirection. Dup'ing.
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 364188
Keywords: testcase-wanted
v. duplicate. I removed the params (note I had to save page as.. from Chrome because Firefox's parsed html was wrong already) and the page displays fine.
You need to log in before you can comment on or make changes to this bug.