Closed Bug 527032 Opened 15 years ago Closed 14 years ago

Meteoblue renders no content (upvar 2 regression?)

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: ptomes, Unassigned)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [3.6.x])

Attachments

(6 files)

Screenshot: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre
166.53 KB, image/png
Details
Screenshot: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre
119.67 KB, image/png
Details
Screenshot: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
224.48 KB, image/png
Details
Screenshot: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre (.NET CLR 3.5.30729)
230.29 KB, image/png
Details
Screenshot: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre (.NET CLR 3.5.30729)
167.49 KB, image/png
Details
Screenshot: Mozilla/5.0 (Windows; U; Windows NT 6.0; cs; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
287.66 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1

Content missing: http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed

Previous stable version of Firefox and other browser functioning correctly.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed
Actual Results:  
Content (forecast) missing

Expected Results:  
Content rendered - as in Firefox 3.5 and other browsers.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091106 Namoroka/3.6b2pre

Confirmed, I can reproduce this sometimes. I see it only when the site is in the cache and if I do a normal reload. If I do f5 I can't reproduce it (so far).
Status: UNCONFIRMED → NEW
Component: General → Networking: Cache
Ever confirmed: true
Keywords: qawanted
Product: Firefox → Core
QA Contact: general → networking.cache
Version: unspecified → 1.9.2 Branch
Flags: blocking1.9.2?
Keywords: regression
Ria: can you find a regression range? I can confirm it as well with the following steps:

1. Go to http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed
2. Notice the pretty detailed forecast
3. Focus the Location Bar, hit Enter again

Expected: the same site
Actual: the main content area doesn't get redrawn
Unlike Ria, though, I can't get the site to reload with the button or even a shift+reload command; I have to remove it from the cache before it will re-render.
cc'ing vlad, as I seem to recall we did some cache work for WinCE, but I don't know if that would have caused this.
Nope, no cache work happened for CE -- we have some stuff we want to do (bug 513074) but it hasn't happened yet and won't for 1.9.2
Jonas, can you have a look at what's going on here? Missing layout notifications, or stuff not getting through the parser?
For what it's worth, this regressed between 2009-03-01 and 2009-05-01 as far as I can tell.  I'll narrow it more later tonight.
Ok, the regression is from 2009-04-06-03 (rev b14428284d51) to 2009-04-07-03 (rev f0507c4d0abb).  Pushlog:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b14428284d51&tochange=f0507c4d0abb

Of the things in that list, the TM merge looks most likely, sadly.  :(
Local bisect shows this is an upvar2 regression.  Brendan, I'm really sorry about the state of this bug testcase-wise... :(
Assignee: nobody → general
Blocks: 452598
Component: Networking: Cache → JavaScript Engine
QA Contact: networking.cache → general
No longer blocks: 452598
Summary: Meteoblue renders no content → Meteoblue renders no content (upvar 2 regression?)
Need a blocking decision here for mozilla-1.9.2.
Anyone test tracemonkey builds since the fix for bug 528082 went in?

/be
I just did; it's still broken.
Flags: blocking1.9.2? → blocking1.9.2+
Can we get some help with capturing a local test case?
Assignee: general → brendan
Henrik, can you capture a locally hosted version?

/be
Martijn is our testcase minimizing guru. Martijn, would you have time for? I'm in the middle of blocklisting work...
Still broken?

/be
Yes, as of t-m rev 7a277b27a659
This works for me, tracemonkey repo with tip at f8d3f3df9691, on Mac and Windows. Did it just get fixed today by one of the patches that landed on tm?

/be
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
I see the problem with that exact rev, on mac (debug tracemonkey browser build).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Any profile details? Do you see it in safe mode? Jit off? Help me out, I am unable to repro.

I tested in a fresh profile, jit on by default.

/be
Just retested in a clean profile, opt build, not safe mode, rev f8d3f3df9691.  The problem reproduces just fine.
More info.  I'm using beltzner's steps from comment 2.  Sorry for not making that clearer before.  There are no extra errors when the bug happens, and the "cname is not defined" error does appear.  If the error console is open during step 3, the bug does NOT appear.
Oh, and I see the bug whether jit is on or off.
bz: can you try repro'ing with upvar2 optimizations turned off? I wonder if this isn't some latent bug todo with timers, XHR, or whatever is going on between the app/page, the server and the console (if up).

/be
> can you try repro'ing with upvar2 optimizations turned off?

How would I turn them off?

If you tell me exactly what to do, I can try to take a few mins to do it tomorrow.
This hasn't been touched in a month; still a blocker?
so, this works on trunk now. looking for a regression/progression range.
(In reply to comment #27)
> so, this works on trunk now. looking for a regression/progression range.

Working on it.
(In reply to comment #27)
> so, this works on trunk now. 

Is that tip, or the 12/21 nightly? Because I can still repro with the 12/21 nightly on both m-c and TM.
correction!

this is not a regression from 3.5. They're all broken if you visit with the site cached. We'll take a patch in a point release for this, since 3.6 is no worse.
Flags: wanted1.9.2+
Flags: blocking1.9.2-
Flags: blocking1.9.2+
Whiteboard: [3.6.x]
Uh...  This worksforme on 3.5, and we had a post-3.5 regression range in comment 8.

Renominating.
Flags: blocking1.9.2- → blocking1.9.2?
(In reply to comment #31)
> Uh...  This worksforme on 3.5, and we had a post-3.5 regression range in
> comment 8.
> 
> Renominating.

But comment 8 is not post-3.5, is it?
It's m-c after 3.5 branched.  But I guess we did land upvar2 in 3.5...

OK, I can see not blocking on this.  :(
Though note that I still think that "we didn't find this bug before shipping the previous release" is not a sufficient justification for not blocking the next one, no matter how much we use it....
I agree that *when* we discover a bug shouldn't affect the blocking decision. However, the fact that so few web users have been bitten by this regression speaks to the relative priority of the fix.

Nominated for point releases.
blocking1.9.1: --- → ?
blocking2.0: --- → alpha1
Flags: blocking1.9.2? → blocking1.9.2-
So is this really an upvar2 regression?

I'm a terrible owner, likely to be worse in the new year (new work beckons). JS team has many brave and mighty hackers now. Throwing into the pool for sayrer to reassign from.

/be
Assignee: brendan → general
> So is this really an upvar2 regression?

Yes, it really is.  upvar2 landed in 3.5 (which I had not realized).
As a 10 years contributor of Mozilla project (fan, promoter, tester, translator, localizer, CZilla.cz and firefox.czilla.cz contributor and so on) I actually can not underestand why are you doing five beta releases and look very much for testers when it is for them waste of time to report regressions of functionality as early as possible (first beta). I've just tried http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed in Firefox 3.5.6, 3.5, 3.0.16, 3.0, 2.0.0.20, 2.0, 1.5.0.12, 1.5 and I can not imagine how you want to launch and ship new release with known and early reported broken rendering which worked fine in all Firefox versions in last 5 years at least. This bug is probably not connected just with Meteoblue.
I strongly believe that Firefox users deserve rendering which worked properly ever since to be working in future, too. Similary bug reporters deserve to know if this project really need their time and effort.
At the very least I hope patch to be ready before Firefox 3.5 users are prompted to upgrade to Firefox 3.6.x.
Petr, the point is that the site is also broken in Firefox 3.5.x, at least using the steps to reproduce from comment 2.
(In reply to comment #39)
Boris, I've just check it (http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed) up in Firefox 3.5.6 on Windows XP again and the main content area has got redrawn. How it is possible? Should I send screencast to be believed or help in some other way?
Petr, can you figure out, using mozilla-central nightlies, when this bug first appears for you?  Robert is seeing it with 3.5, and I'm seeing locally that it was caused by a change that was also made in 3.5...  It might be that there's more than one thing going on here.
(In reply to comment #41)
Boris, I can see http://www.meteoblue.com/index.php?id=246&L=&did=135&zf_f=1785&zf_c=cz&zf_tab=detailed working well on:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-19-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre

The first build which is broken is ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-20-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre

Thus, how it is possible to be this bug connected with 3.5? As I've already said, 3.5 and 3.5.6 is working well for me. Should I try to find more testers with other operating systems?
Mmh, I don't see any difference (content is loaded) between 3.5 and 3.6 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b6pre) Gecko/20091227 Namoroka/3.6b6pre ID:20091227033656

Petr, can you please upload two screenshots which will show the difference? Thanks.
Petr, both of those builds are chronologically before 3.5.0 was shipped....

That said, that range doesn't seem to include the changeset which seems to cause the problem on mozilla-central.  I guess I'll try bisecting on the 1.9.2 branch and see what I find.  Thanks for getting me that range!
Henrik: are you using the steps in comment 2?
(In reply to comment #45)
> Henrik: are you using the steps in comment 2?

Yes, I do.
FWIW, I'm using 3.5.6 here on WinXP Home w/SP3, no add-ons.
I visited the site in the URL, and following the steps, clicking into the location-bar, and hitting enter, renders the content every time for me, I have not yet after repeated attempts, to get the blank page others are reporting. 

So.. with that, I'm not sure the problem exists in 3.5.x steam, and thus should probably block if its failing in 3.6 pre builds. 

I will retest with latest trunk when I get home.
Next 3 screen shots are coming. Again with clean profile without extensions but this time from another laptop with Vista. These screen shots clearly provide an evidence when the bug was introduced on Windows platform and that Firefox 3.5.x rendering is fine.
Er, except the range in comment 42 is on mozilla-central, not 1.9.2.  Petr, I can reproduce the bug with earlier nightlies than that on mozilla-central, by over a month.  See comment 8.
Jim, are you seeing the same m-c or 1.9.2 regression range as Petr is?  Or something else?
(In reply to comment #55)
> Jim, are you seeing the same m-c or 1.9.2 regression range as Petr is?  Or
> something else?

This whole report is getting sorta messy, I'm reporting that on release builds, 3.5.6, there seems to be no issue with the site.  I will test with m-c when I get home in about an hour and half.

Unless I'm mis-reading, there seems to be some that see this on the current release version, but I'm not seeing anything with the current release (3.5.6)
Drat, this needs an edit at times, I meant by 'I'm not seeing anything with the current release"... that I'm not seeing any issues with the page, even with several reloads.
FWIW, I don't see this problem in 3.5.6 (both using my 'dirty' extension driven
profile and a fresh profile). 
I do get this bug in both 3.6 and 3.7, using a fresh profile. UA:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b6pre) Gecko/20091228
Namoroka/3.6b6pre (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091227
Minefield/3.7a1pre (.NET CLR 3.5.30729)

Using Win Vista Home Premium SP2 on a Intel core2 Duo E6750.

Update after mid air collision:
I sometimes get this on 1.9.2 20090519.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre

I can accurate reproduce this on 1.9.2 20090520, the page stays empty a lot more often then in the previous build.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre

Also tried 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090415 Minefield/3.6a1pre
Both got this bug. It did take many reloads to make the page go empty in 20090318, but once it did go empty, it suddenly wend empty half the time (but randomly display again after a normal reload (f5, or enter on url bar)).

It's very hard to get a regression range for me, since this bug only pop up after a random amount of reloads. Might try again tomorrow if i feel like it, and it's still needed ;)
Hmm.  So it does sound like something else changed on 2009-05-19 to make this happen more...  We need to get a separate bug filed on tracking that.  I'll try to see whether I can figure out what changeset(s) caused that.
Just got home, and the site seems to load fine, even after several clicks into the location bar and hitting enter, I am still not seeing any blank rendering of the forecast. 

Today's m-c build, on Win7 HP, Athlon Phenom II x-4 (quad), 8 gig ram
The site seems to take a bit longer to reload the page after hitting enter than it did on my XP SP3 machine at work, but its on cable, and at home I'm on DSL, so perhaps that's playing into the load times. 

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091228 Minefield/3.7a1pre Firefox/3.6 ID:20091228043113
I tested on one Vista SP 1 laptop and one XP SP 3 laptops on two different towns (Sokolov, Brno) with UPC Broadband connections (8 Mb/s download, 1 Mb/s upload - speed checked) in the Czech Republic: http://www.lgi.com/europe.html
Summary:
Tested on Fujitsu Siemens Amilo Pro V3505 (Intel Core 2 Duo 1.66GHz, 1 GB RAM); Windows XP SP 3; UPC Broadband 8 Mb/s download, 1 Mb/s upload; always tested with clean profile without extensions. In most cases I had a chance to check it on other laptop with Vista and wifi router connected to UPC broadband in same town and on same laptop in other town but same provider I get the same results.

I can not reproduce the bug in no case of 10 times in a row with the following builds:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-18-05-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-06-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-07-09-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090407 Minefield/3.6a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/04/2009-04-15-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090415 Minefield/3.6a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-19-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre

Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6

But I can reproduce the bug on every reload with the following builds:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/05/2009-05-20-04-mozilla-central/firefox-3.6a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090520
Minefield/3.6a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-3.7a1pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091228 Minefield/3.7a1pre

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/firefox-3.6b6pre.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b6pre) Gecko/20091228 Namoroka/3.6b6pre

Thus it seems to me this bug is not connected with one hw or sw configuration. Dorus Peelen commented here he has no issues with Firefox 3.5.6 using Win Vista Home Premium SP2 on a Intel core2 Duo E6750 (the same result as me and Jim Jeffery on Windows 7) and he has issues every time or most time with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090520 Minefield/3.6a1pre (I have the issue always here). But Dorus sometimes has issues with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090519 Minefield/3.6a1pre and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre and Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090415 Minefield/3.6a1pre while those build works correctly for me at all times. But Dorus like me reports the bug on 3.6 and 3.7. Henrik Skupin don't get the bug with Firefox 3.5 and also with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b6pre) Gecko/20091227 Namoroka/3.6b6pre ID:20091227033656
What can i say? You have to be really persistent to hit this bug on 20090318 Minefield/3.6a1pre (sometimes takes me 25 reloads, after with the next 5 go wrong in a row). On Gecko/20090520 Minefield/3.6a1pre it only takes 1 to 3 reloads.
I hit this bug about every third reload on the 2009-05-19 mozilla-central build.  I hit it on about 70% of reloads in the 2009-05-20 mozilla-central build.

I'm trying to narrow down when the jump happened, but it's taking a while to gather enough statistics to be pretty sure...
Ok.  So _if_ I'm testing this right (and there's a lot of noise in the measurements), the frequency of failed reloads increased after the fix for bug 481566 (changeset 11a3e4008446).  

At a guess, this just made the underlying problem easier to tickle somehow... All it does is change the frequency at which we flush out the sink and frame construction.

If someone who can reproduce this reliably can try playing with the preferences that bug introduced to see which (if any) of them have an effect on this site, that would be much appreciated.
Blocks: 452598, 481566
Petr, we definitely appreciate your testing efforts. But please realize that other people might be seeing different behavior than you are. Even if you can't reproduce the problem in 3.5.x, it's entirely possible that others can. The more people that we have testing, the better, but please don't make it sound like there is a big conspiracy or that we're not believing what you're saying just because others are getting different results than you are.

There could be several problems causing the same symptom here, and it's possible that some of these problems only show up on some systems. Or it could be that there are timing issues or something similar making things behave differently on different systems.

We all want is to try to figure out how to fix the problem, but given that so far given that this problem has only showed up on a single site, and we don't yet have a clue what the problem on that is, I agree with Mike that we can't hold up the 3.6 release at this stage.

What would be immensely helpful is if you could try to create a smaller testcase. Given that the problem seems to reproduce very reliably for you it would be immensely helpful if there was a minimized testcase.

That way we could spend time on trying to fix the problem in 3.6, rather than trying to figure out exactly what broke it.

And thanks again for your help so far!
Blocks: upvar2
No longer blocks: 452598
(In reply to comment #66)
I am not a computer programmer, I really don't know how to create testcase. :( I start to underestand reasons why not to block 3.6 for that at all costs. Thank for all people involved in reporting and seeking solution.
I've just got e-mail reply from Meteoblue. They are preparing website upgrade "for end January, which should solve the problem".

But I still believe the bug deserve to be fixed in Firefox, too. In a month there won't be any further testing possible with Meteoblue URL. Testcase should be prepared by that time.
If they could tell us what behaviour on our end broke them, that would help a lot. We' re still sort of in the dark here as to what's actually going wrong.
It's still unclear from this bug report if this bug affects the 1.9.1.x branch, so clearing the nomination; if we can figure out what is causing the problem, and determine that the problem still exists on 3.5.x, please renominate or put the patch up for approval.
blocking1.9.1: ? → ---
blocking2.0: alpha1 → beta1
blocking2.0: beta1+ → beta2+
blocking2.0: beta2+ → final+
(In reply to comment #68)
> I've just got e-mail reply from Meteoblue. They are preparing website upgrade
> "for end January, which should solve the problem".
> 
> But I still believe the bug deserve to be fixed in Firefox, too. In a month
> there won't be any further testing possible with Meteoblue URL. Testcase should
> be prepared by that time.

No test case, and the site works in 3.6 and 4.0.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: