'o is undefined' when accessing some strings on Verbatim

RESOLVED FIXED

Status

Webtools Graveyard
Verbatim
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: stas, Unassigned)

Tracking

Details

(Whiteboard: [better verbatim])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
The localizers have been hitting this bug since Friday but I wasn't able to reproduce.  First I thought it was related to a particular nightly, but today I also see in Google Chrome.

This the URL that gives me an empty page (only Verbatim's header and footer is displayed):

https://localize.mozilla.org/pl/badges/LC_MESSAGES/messages.po/translate/?unit=850420

I also heard that the following one didn't work either, but I still can't repro:

https://localize.mozilla.org/rm/twitterparty/LC_MESSAGES/messages.po/translate/?unit=849893

The errors in the console are:

[18:43:40.632] o is undefined @ https://localize.mozilla.org/html/js/jquery/jquery.scrollTo.min.js:11
[18:43:40.981] $.pootle is undefined @ https://localize.mozilla.org/html/js/mt/google-translate.js:7

This is blocking some languages and we have a lot projects going on right now for the launch of Firefox.  It would be great if this is fixed quickly.
I tried several methods to reproduce it basing on feedback from @lzyczkowski.

 - tried Opera, Chrome, Firefox 3.6, Minefield
 - tried Linux and MacOS (Teo reproduced it on WinXP, I don't have it)
 - tried with a temp account with different privileges to the project
 - tried with some of the extensions that Teo uses (including AdBlock)

I was unable to reproduce it at all :(
(Reporter)

Comment 2

7 years ago
I can show it to you on my machine on Tuesday.
(Reporter)

Comment 3

7 years ago
BTW it looks like this only happens when the user is logged in.

Comment 4

7 years ago
Some detail description about this bug:
This happens only if I'm logged in. To string #25 all is OK. After click string #26 I see only Verbatim's header and footer. See attached screeshot and try this link after logged in. https://localize.mozilla.org/pl/twitterparty/LC_MESSAGES/messages.po/translate/?unit=849893

Comment 5

7 years ago
Created attachment 517291 [details]
Screenshot for this bug
@Stas: so you are able to reproduce it after all?
(Reporter)

Comment 7

7 years ago
Yes.  See below.

(In reply to comment #0)

> This the URL that gives me an empty page (only Verbatim's header and footer is
> displayed):
> 
> https://localize.mozilla.org/pl/badges/LC_MESSAGES/messages.po/translate/?unit=850420
I get the same bug on this URL: https://localize.mozilla.org/it/glow/LC_MESSAGES/messages.po/translate/?unit=865176 (last string, 21st, of global map project)
Oh, andm since Stas asked for it... My OS is Debian testing, the browser is Firefox 3.6.15 (x64 self-compiled based on Mozilla sources)

Comment 10

7 years ago
I can't reproduce this either.

It's a little bit surprising the state of the page as seen on the screenshot (no content displayed at all) based on the JavaScript errors reported in comment #0, since Pootle 2.1.x doesn't require JavaScript to work with the editor.

I doubt this could be the issue, but you can try disabling the scrollTo plugin functionallity with a simple patch:
http://paste.pocoo.org/show/350093/

Are there any similarities in the browsers of the affected parts? installed extensions perhaps? is this a Firefox-only issue? does it only happen on certain languages?
(Reporter)

Comment 11

7 years ago
Gandalf and I were able to debug this and find the reason.  

The culprit is the 'Number of Rows' setting in your account's settings tab:

    https://localize.mozilla.org/accounts/edit/

If this number is too big, Verbatim doesn't show last strings for projects with very small number of strings.

Examples:

My setting was 20 and I couldn't see strings from 11th on in the Badges projects.

I'm guessing that Gion-Andri's and Leszek's setting was 50 -- they weren't able to see the 26th strings of the Twitter Party project.

CC'ing Friedel and Alaa.
(Reporter)

Comment 12

7 years ago
Just to complete the following examples, I'll add the total number of strings below.

> My setting was 20 and I couldn't see strings from 11th on in the Badges
> projects.

Total strings: 12 (<20)

> I'm guessing that Gion-Andri's and Leszek's setting was 50 -- they weren't able
> to see the 26th strings of the Twitter Party project.

Total strings: 41 (<50)
That's a fine job you guys did there figuring this out. Woot!

Comment 14

7 years ago
Created attachment 518317 [details] [diff] [review]
Patch to fix the issue

Just been able to reproduce the bug with the given details, thanks Staś.

This trivial patch should fix it, at least works fine locally.
(Reporter)

Comment 15

7 years ago
Hi Julen,

Thanks for the patch.  I tested it and I'm afraid that it introduces a different problem. 

1. I set my 'Number of Rows' to 50 to keep things consistent with others reporters of this bug.

2. The patch indeed fixes the problem of small projects, like Badges (12 strings) and Twitter Party (41 strings).  Note that all of those are less than my new setting (50).

3. A new problem appears for bigger projects.  I tested with Firefox Cup (60 string).  This should be paginated into two pages: page 1 with 49 strings (as per my setting) and page 2 with 11 remaining strings.

4. However, when I try to access any of the strings no. 50-60, Verbatim shows my strings 1-11 instead.  It tells me that I'm on page 2 and shows me some 11 strings, but they are not the right strings.

Can you see this too?

Comment 16

7 years ago
(In reply to comment #15)
> 
> Can you see this too?

Yes I see. Then checking if it's the first page should be enough I think, otherwise it'll always pick the first units in the queryset.

Comment 17

7 years ago
Created attachment 519250 [details] [diff] [review]
Patch to fix the issue

This should hopefully do the right thing.
Attachment #518317 - Attachment is obsolete: true
What is the status of this bug? I don't have access to Verbatim so cannot verify
(Reporter)

Updated

6 years ago
Whiteboard: [better verbatim]

Comment 19

6 years ago
Has anybody been able to test the patch (attachment 519250 [details] [diff] [review])? It would be great to have it confirmed and in the next release.
Peterbe, do you have a working dev instance of verbatim handy and can help out the Pootle guys with comment 19?
(Reporter)

Comment 21

6 years ago
I tested this with Peter today and I wasn't able to reproduce.  Upon investigation, it turned out that the lines that Julen's patch would remove are now gone in the code -- the bug must have been fixed by one of the regular Pootle updates on the Verbatim server.

Thanks everyone!  Resolving fixed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

2 years ago
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.