Search http://www.google.com on Le Creuset Brittany/Traditional Tea Kettle Results: -I consistently have about a 500 pix tall white space (the height of 6 ads at the right) -Gecko/20020702 commercial branch whether sidebar tab is open or closed -7/3 pull on embedded browser -Marcio sees the gap if he closes his sidebar tab -Using 7/16 commercial branch Whoever diagnoses it can have my used teakettle if desired (hand delivery in Mountain View only). If it's an evang issue I have a contact.
It looks like Mozilla is refusing to wrap the address because it has no spaces in it. Therefore, so it does not have to wrap it, it forces the url below the floating table. I believe the only solution is evangelism because Mozilla's behaviour is correct. The problem would be avoided if Google put <br>s in the middle of long address/titles (like the one immediately below the search box). I'd be surprised if they actually did that, though, since IE wraps it anyway.
Created attachment 91958 [details] Source code with BR in line that isn't wrapping Adding <br> in the string of text that isn't wrapping fixes the problem. We can't expect Google and other sites to manually add <br>s when they think this problem will occur. <a href=http://www.epinions.com/hmgd-Small_Appliances-All-Le_Creuset_Brittany___Traditional_Tea_Kettle>www.epinions.com/hmgd-Small_Appliances-All<br>-Le_Creuset_Brittany___Traditional_Tea_Kettle</a> Comparisons: -Wraps in IE 6 -In Navigator 4.x the long string of text overlaps the ads at the right
added keywords, changed summary
Assignee: attinasi → karnaze
Severity: normal → major
Keywords: nsbeta1, topembed
Summary: Large white space in Google search results → Long text string not wrapping in Google search results -->white space
changing to P1
Severity: major → normal
Priority: -- → P1
Frank/Shanjian - Perhaps this is related to http://bugscape.netscape.com/show_bug.cgi?id=17976 If that gets fixed, and this can be at the same time that would be great. (I noticed the URL I originally reported has different search results so you can't see the problem live but just read the description.)
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM] [ETA Needed]
Target Milestone: --- → mozilla1.0.1
> Frank/Shanjian - Perhaps this is related to > http://bugscape.netscape.com/show_bug.cgi?id=17976 These sound like different bugs to me. In this case, the ASCII string in question has no whitespace and has no places it can be wrapped. In the case of bugscape 17976, there are places where the line can wrap, but is not doing so.
I think we should aim to make the behavior on par with IE.
Is this really a regression?. Should that keyword be removed? It sounds like Mozilla is behaving according to spec and there isn't any indication that it worked differently in an earlier build. From the comments in the bug it sounds like what is being asked for is quirk compatibility with IE. If thats the case then the compat keyword should be added.
Good point. Done.
Keywords: regression → compat
I'm not seeing the problem with a current trunk or branch build. Have the search results changed or am I missing something?
Created attachment 100061 [details] Google results with issue Yes their search results have changed. Attached is the original code with the issue. The first attachment shows how it lays out when you have a break in the long string (i.e. correctly). You have to be at 800x600 to see this. Then compare in IE.
Adding dbaron to the cc list. I still haven't lowered my resolution to see the bug, but from the comments, it sounds like it would be a nasty quirk that may even break other pages.
I don't understand what screen resolution has to do with this. I see a big gap if I shrink the width of the browser window. That gap seems to me to be the correct behavior (although it's ambiguous in CSS2), and I thought it is what IE does as well.
So is the issue here related to reflow behavior or is it related to line-breaking behavior? I recall some bug with a debate about whether or not to break on "-".
using today's winxp build, 800x600 res, and the test attachment, I am not able repro this. juan can't repro w/ winxp, 1.0 branch build, 800x600 either. if this becomes a more reproducible issue; please re-nominate.
Keywords: topembed → topembed-
wfm based on last comment.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
*** Bug 255110 has been marked as a duplicate of this bug. ***
i still see this issue. the URL i gave in bug 255110 still isn't getting wrapped like it does in IE and it causes the layout to not look as intended. here it is: http://www.axisoflogic.com/artman/publish/article_10776.shtml could somebody with the proper bits reopen this?
bill: as the reporter, you should be able to reopen this. what say ye?
err... that would be susie and her email address is @formerly-netscape.com.tld :( dbaron? do you have the bits to reopen this?
15 years ago
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
*** This bug has been marked as a duplicate of 218580 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.