Working on bug 213245 I found, that form on that page locked my Mozilla down. I simplify page and found, that source of locking up is to manu unclosed <option> tag's in RTL direction. If number of unclosed <option> tag's is less than 10, page always work correctly, but with 20-30-40 unclosed tag it become locking. To produce this effect you need open following testcase and try to use select menu several time (but try to switching fast, I don't clearly understand, but if I selected option slow, with big pause, everything could be normal). It take me 2-10 clicks to lock-up Mozilla's. CPU usage is over 100% and task is not answered, same picture in Linux Mozilla.
Created attachment 128467 [details] Same as attachment 128156 [details], but with the closing tags This seems very surprising. I don't see why omitting the closing tags should have any effect, but I can reproduce the hang with attachment 128156 [details] and not with this one. The hang seems to be a mutually recursive loop of nsFrame::GetNextPrevLineFromeBlockFrame() and nsFrame::PeekOffset()
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).