Closed Bug 69785 Opened 24 years ago Closed 23 years ago

[FIX] form listboxes missing (<inline><select></inline> hides the listbox)

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: db, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: regression, top100)

Attachments

(5 files)

Bugzilla screenshot where status options are missing
37.43 KB, image/gif
Details
Testcase [ Note: removing the size attribute resolves the problem ]
330 bytes, text/html
Details
reduced testcase without table
162 bytes, text/html
Details
previous testcase shows it works for combos, this show how it doesn't work for listboxes
162 bytes, text/html
Details
Patch to fix it.
751 bytes, patch
Details | Diff | Splinter Review 
Go the the page in URL and press the search button at the to row. Here there
should be three listboxes in the top, but the Category and Manufacturer
listboxes are gone.

In linux build 2001021308 it still works but in 2001021921 they are gone.
Looks like the missing listboxes are in <nobr> tags while the non-missing one is
not.

Works in 2001-02-13-08, as reporter says.  Does _not_ work in 2001-02-13-21.

Possibly related to bug 69722 (also select multiple, same timeframe of regression)
Keywords: regression
Yes, it is a <nobr> issue - reassigning
Assignee: rods → harishd
Confirming as per comments. I'm sure this has a duplicate, but I can't find it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Suggesting changing OS to All since I can confirm it on Win98 (screenshot
attachment following).
Not able to access the above URL. Please update.
Status: NEW → ASSIGNED
Whiteboard: UNABLE TO ACCESS THE ABOVE URL!
The URL works fine now when I tried it. Please try again.

This site have been up something like 4-5 years looking more or less the same.
Whiteboard: UNABLE TO ACCESS THE ABOVE URL!
setting to m0.9.
Target Milestone: --- → mozilla0.9
*** Bug 71863 has been marked as a duplicate of this bug. ***
No chance for 0.8.1 huh?
Uhmm..may be we should ask the layout people. Intially, I thought that this 
could be a parser bug but now I doubt that ( since parser doesn't deal with 
processing attributes ). Dumping frames does show the select frame being 
created. This must be a rendering bug. Giving bug to Rods to explore further ;-)
Assignee: harishd → rods
Status: ASSIGNED → NEW
Send to core layout, I am not sure why it is placing the listbox at a large 
negative "y" value.
Assignee: rods → attinasi
CC'ing waterson in case he was mucking about in layout recently, or has a clue 
how this may have regressed. Accepting, and will investigate.
Status: NEW → ASSIGNED
*** Bug 71183 has been marked as a duplicate of this bug. ***
Marc, are you sure this bug is about the same as that duplicate
("<foo><select></foo>")?

If so, I will try and investigate this today.
OS: Linux → All
Summary: form listboxes missing → form listboxes missing (<foo><select></foo> hides the listbox)
Increasing priority: causes form controls to be lost and invalid data to be
submitted
Severity: normal → major
Priority: -- → P1
I'm certainly no expert in this area, but this is looking more and more like a 
block-in-inline problem. 
* First, the behavior has changed in the past couple of days: before, the select 
and the options were missing, now the options are there but the select part is 
still gone (eg. no frame around the selects). 
* Secondly, if I make the select element display:block it shows up fine (except 
that it is, well, a block, so it is on its own line). 
* Third, tracing through the FrameConstruction code I see that an Area frame is 
created for the Select in ConstructSelectFrame, and that is a block, however the 
select is an inline element with display:inline in its style struct, so lots of 
code thinks it is inline. When the options are processed, there is no special 
handling like I see when I make a block a child of a 'normal' inline. OK, so 
here is where I start waving my arms about... I'm hoping Chris Waterson can help 
out here, as he understands the block-in-inline situations much better than I 
do.
Updating summary: select in inline is the problem.
Summary: form listboxes missing (<foo><select></foo> hides the listbox) → form listboxes missing (<inline><select></inline> hides the listbox)
The broken <select> now seems to appear at the upper left hand corner of the
broser, covering some of the content of the page. _Very_ ugly.

Is <inline> a specific html tag? If so, what happened to <small>, <font>, etc,
etc, etc from all the dupes... my experience with html is limited.

Any chance of fixing this by 0.9? If so, would someone please add the
appropriate keyword?
*** Bug 73081 has been marked as a duplicate of this bug. ***
We are shooting for Mozilla 0.9 - see the Target Milestone. Also, the <inline>
notation is to indicate that it happens in any inline element, like <small>,
<font>, etc. <inline is not a real element.
*** Bug 69984 has been marked as a duplicate of this bug. ***
*** Bug 75370 has been marked as a duplicate of this bug. ***
*** Bug 75536 has been marked as a duplicate of this bug. ***
*** Bug 75539 has been marked as a duplicate of this bug. ***
*** Bug 75781 has been marked as a duplicate of this bug. ***
12 dups all told and growing...
Keywords: mostfreq
Ugh - this is bad. I only wish I could get a clue and fix it! I'm feeling very
slow and lame, but still trying.
OK, regrettably moving off to 0.9.1 since it is unlikey I can fix this by 0.9
cutoff. Still P1 for me though.
Target Milestone: mozilla0.9 → mozilla0.9.1
This bug makes searching for jobs that little bit more "interesting", see the
result of http://jobsearch.monster.co.uk/ :(

*** Bug 77278 has been marked as a duplicate of this bug. ***
*** Bug 77068 has been marked as a duplicate of this bug. ***
*** Bug 77899 has been marked as a duplicate of this bug. ***
monster.com in its various incarnations is a top100 site....
Keywords: top100
The problem seems to be with the scrollframe that wraps the SELECT when it is a
listbox. This is a strange case because it is a scroll frame around an inline
element. In any case, the origin of the scroll frame is getting computed
incorrectly. I'm starting to instrument the scrollframe, but I'd appreciate some
help from the scrollframe-master, so cc'ing Eric Vaughan.
Severity: major → critical
*** Bug 77926 has been marked as a duplicate of this bug. ***
Comments from bug 77926 (probably more symptoms, but may point at something
useful):

The <select> list in the middle of the page doesn't display hilighting when
items are selected. If you drag the window offscreen then back on, or minimize
it and restore it, the listbox redraws correctly. [ie the item that was clicked
is highlighted]
What Boris said; a reflow makes the row you clicked selected.
You mean a repaint, right? 

That is interesting, but I noticed that in that case, like the testcases I am
working on, the actual 'select' is missing (note that the frame around the
options is not there. The problem appears to be with the location of the
select's scrollframe.
*** Bug 77994 has been marked as a duplicate of this bug. ***
I think I may have made some progress - not surprisingly, it has nothing to do
with line layout, block frames or the other stuff I have been laboring over for
days now :)  The View for the scrollframe is invisible, and if I force it to be
visible in the debugger then the select appears and acts correctly. This may
have to do with the switch to the new view manager, or it may not, I'm not sure,
but the nsScrollFrame has not changed in a while. I'm now tring to figure out
how to get the views set to visible, whihc just might fix this. Shouldn't take
more than another month ;)
The new view manager still has a pref, by which you can reenable the old one, to
help rule out bugs.  Cc'ing roc.

/be
Yea, the old view manager is even worse ;) I'm not sure if it has started to rot
or not, but when I disable the 'scary' view manager even the options don't show
up. I have no reason to believe that the new view manager is doing anything
wrong, I was just guessing since I cannot find the actual guilty code. 
The problem is that the view for the scrollframe is hidden in the Init call and 
then never set to visible when inside of an inline. When inside of a block, the 
container frame handles resetting the visibility.

This is a regression caused by a change to nsScrollFrame (ver 1.160) by 
pinkerton. CC'ing to find out why Carbon needs the scrollframe to have its view 
hidden even when it really needs to be displayed (the CVS comment jsut says 
Carbon changes).

Patch to fix it coming (simply rolls back pink's change).
Summary: form listboxes missing (<inline><select></inline> hides the listbox) → [FIX] form listboxes missing (<inline><select></inline> hides the listbox)
Attached patch Patch to fix it. — — Splinter Review 

    
    

    
  
For what it counts, Marc's patch looks fine to me.

    
    

    
  
Fix checked in. nsScrollFrame.cpp v1.162
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED

    
    

    
  
verified fixed on Linux on a random sampling of 5 of the dups.  Build 2001-05-07-08

    
    

    
  
*** Bug 79452 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 79439 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 79468 has been marked as a duplicate of this bug. ***

    
    

    
  
Checked into branch (0.9) too.

    
    

    
  
*** Bug 79725 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80260 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 80941 has been marked as a duplicate of this bug. ***

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
also verifying on build 2001-05-15-04-trunk windows 98 and closing the bug

    
  
Blocks: 75664

    
    

    
  
*** Bug 82862 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 69816 has been marked as a duplicate of this bug. ***
Component: HTML: Form Submission → DOM: Core & HTML

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: