Long text string not wrapping in Google search results -->white space




17 years ago
15 years ago


(Reporter: susiew, Assigned: karnaze)


({compat, topembed-})

compat, topembed-

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt2 RTM] [ETA Needed], URL)


(2 attachments)



17 years ago
Search http://www.google.com on Le Creuset Brittany/Traditional Tea Kettle

-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.

Comment 1

17 years ago
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.

Comment 2

17 years ago
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. 


-Wraps in IE 6
-In Navigator 4.x the long string of text overlaps the ads at the right

Comment 3

17 years ago
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


17 years ago
QA Contact: petersen → moied

Comment 4

17 years ago
changing to P1
Severity: major → normal
Priority: -- → P1

Comment 5

17 years ago
Frank/Shanjian - Perhaps this is related to

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: regression


17 years ago
Blocks: 143047


17 years ago
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 RTM] [ETA Needed]
Target Milestone: --- → mozilla1.0.1

Comment 6

17 years ago
> 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.

Comment 7

17 years ago
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.

Comment 9

17 years ago
Good point. Done.
Keywords: regression → compat


17 years ago
OS: Windows 2000 → All
Hardware: PC → All

Comment 10

17 years ago
I'm not seeing the problem with a current trunk or branch build. Have the search
results changed or am I missing something?

Comment 11

17 years ago
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.

Comment 12

17 years ago
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 "-".

Comment 15

17 years ago
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-

Comment 16

16 years ago
wfm based on last comment.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 17

15 years ago
*** Bug 255110 has been marked as a duplicate of this bug. ***

Comment 18

15 years ago
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:

could somebody with the proper bits reopen this?

Comment 19

15 years ago
bill: as the reporter, you should be able to reopen this.  what say ye?

Comment 20

15 years ago
err... that would be susie and her email address is @formerly-netscape.com.tld :(

dbaron?  do you have the bits to reopen this?

*** This bug has been marked as a duplicate of 218580 ***
Last Resolved: 16 years ago15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.